Services
Quality and compliance in the pipeline
Legal, SEO, accessibility and security requirements become automatic gates in CI/CD that fail the build instead of ageing quietly in a document.
A requirement written into a document gets read once, remembered for a week and forgotten. A requirement written into the pipeline fails the build every time it stops being met. That difference is what the first service pillar is built on.
A client's requirements - legal, SEO, accessibility, security - turn into assertions that check the generated page itself, not the intention written into a policy. An assertion passes or it does not. There is no third option, and no waiting for the next audit to find out.
The advantage on offer is methodical, not thematic. It is not a list of technologies or a certificate on the wall, but a way of working: every requirement gets a test, every test goes into CI, and every subsequent code change passes through the same gates as the one before it.
The method is applied to the company's own code first. search-quality-kit is an in-house package, public on npm: 58 TypeScript source files, 10,038 lines of code, 30 test files. It audits a page's technical foundations - crawlability, metadata, structured data and baseline accessibility among them - and runs in the CI pipeline of three services the company maintains, including the one this page belongs to. It has never once appeared as a line item in the service offering itself.
A second example comes from the same repository. A new requirement under Polish electronic-communications law, mandating consent before a third-party embed loads, became a single assertion in a script called check-build-output.mjs: it checks that the contact page does not embed a Google Maps address before the visitor has given consent. The error message states the rule directly: "Contact page must not embed Google Maps before consent; the map is gated behind the embeds category." If the map is ever restored without consent, the same build that passes today stops passing.
This pillar covers legal requirements among others (consent and data retention, for example), SEO, accessibility and the security of the build process itself. It does not cover external audits or certification preparation as a separate service - the requirement gets built into code that is being written anyway, instead of adding a document alongside it.
Technologies used
- Quality gates in CI/CD (GitHub Actions)
- Assertions on the generated build (HTML, JSON-LD, sitemap), not on a document
- search-quality-kit - an in-house npm package for auditing a page's technical foundations
- Node.js and TypeScript for in-house validation scripts
- Requirements versioned together with the code in Git, not in a separate document
- Tests as the specification of the requirement, not only a safeguard against regression
What it delivers
- A requirement written into code once applies to every subsequent deployment, not only on audit day
- A regression stops the build before it reaches production, instead of waiting for someone to notice it by hand
- The requirement and the deployment never drift apart in time, because they live in the same repository
- A requirement failure looks exactly like a unit test failure - it shows up in the same CI log
Example use cases
- A gate that enforces consent for embeds (maps, video, advertising pixels) before the visitor gives it
- A gate that checks every generated page for the required metadata, structured data and canonical addresses
- A gate that keeps pages covered by a legal information notice out of the sitemap meant for indexing
- A gate that checks baseline accessibility thresholds in the built version of the page before it reaches production