Skip to main content
Skip to content

Resources

The Next.js compliance scaffold most kits skip

Last updated 2 June 2026 · Dan Tinsley, Halbon Labs

Some $59 Next.js kits look good on the demo. They run clean Lighthouse, the components are accessible at a primitive level, the TypeScript is strict. So when a buyer is comparing them against $300 alternatives, the obvious question is: what is the $241 gap actually for?

A lot of it is invisible until you hit week three of customer onboarding. Then someone in procurement asks for your accessibility statement. Or a US state-privacy regime asks where your Do Not Sell page is. Or an EU customer’s legal team wants to see how your site honours GPC. None of that is in the demo. Most kits do not ship it.

The regulatory baseline most kit shoppers do not realise applies

Three pieces of recent legislation changed what a structurally-correct SaaS website needs to render and expose, even at small scale.

EU Accessibility Act (EAA), effective June 2025. It applies to a defined set of products and services (including e-commerce, consumer banking, e-readers, and electronic communications), many of which a SaaS will fall under. Where it applies, accessibility to EU consumers means meeting EN 301 549, which incorporates WCAG 2.1 Level AA, as the baseline (microenterprises providing services are generally exempt). Public procurement, education sector, and enterprise contracts increasingly require a VPAT (Voluntary Product Accessibility Template) documenting your conformance; without one you can be disqualified from those tenders.

UK Data (Use and Access) Act 2025 + the ePrivacy regime. Eight enumerated rights in the privacy notice. Cookie consent with Reject all at the same prominence as Accept all, not buried in a settings panel. GPC honouring required by California (CCPA/CPRA), Colorado, Connecticut and several other US state laws.

EU AI Act. Any AI-interaction or generation surface needs a clear disclosure that users are interacting with, or viewing content generated by, AI, given at or before the first interaction (Article 50). A server-rendered label is the most robust way to guarantee it is present before hydration; a disclosure that only appears in a tooltip after JS executes is fragile and easy to miss.

None of these are “nice to have.” They are audit checklist items. The cost of meeting them after the fact, retrofitted into a codebase that was not built for them, runs at 2-4 weeks of focused engineering work per Deque’s published benchmark.

What “compliance scaffolding” actually means in code

There is a fair argument that most kits do not ship compliance because their target buyer does not need it (a personal project, an indie side-build). For commercial deployment, what should be in the box is structural rather than legal: wiring that lets the buyer drop in their real values and ship a structurally-correct site without rewriting the legal layer.

For a UI-kit-shaped product, the minimum is roughly:

  • Six legal page routes: /privacy/, /terms/, /cookie-policy/, /accessibility/, /dmca/, /do-not-sell/. Server-rendered, no auth required
  • Cookie consent component with Reject all at the same prominence as Accept all, per-category toggles, and navigator.globalPrivacyControl honoured
  • AI disclosure component rendered in the SSR DOM on every chat / agent / playground / generation surface
  • Footer registered-entity block sourced from a configuration constant: company name, company number, place of registration, registered office, contact email, VAT number where applicable
  • A SITE_CONFIG-style schema where the buyer fills in real values once and the scaffold renders correctly across all the surfaces

For a full-stack template, add the backend:

  • A DSAR endpoint (Data Subject Access Request) that returns a downloadable JSON of all user data on request
  • Account-deletion with a 30-day soft-delete window before hard purge
  • An audit_log table seeded in the initial migration, capturing actor, action, table, row ID, timestamp
  • Stripe webhook signature verification on inbound webhooks
  • Password hashing via bcrypt or Argon2id
  • Application-level row isolation that scopes queries per user (RLS-ready)

None of this is exotic. None of this requires Enterprise-tier features. All of it is structural wiring that an experienced backend developer would build in a sprint or two, except they probably will not, because it is not what shipped the demo.

What procurement teams actually audit

Three checks an enterprise buyer’s procurement, legal, or compliance team will run, the moment they are seriously considering a vendor:

1. Show me the accessibility statement. Not a claim on your homepage that you are “WCAG-compliant.” An actual /accessibility/ page documenting WCAG version targeted, known limitations, contact route for accessibility issues, and last-reviewed date. Bonus points if you can produce a per-release VPAT.

2. Show me your cookie consent flow. Open the site in a fresh session, in an EU geolocation. The banner should render before any non-essential scripts load. Reject all should be a button of equal visual prominence to Accept all. With GPC enabled in the browser, the banner should not appear at all and the site should silently treat non-essential cookies as rejected.

3. Show me your data subject access flow. If a user emails you asking for all the personal data you hold on them, what is the technical path? If the answer is “I would open a database client and query their rows,” you will fail any procurement review that takes more than five minutes. The structurally-correct answer is “they hit this endpoint, get a JSON download, and we log the request to our audit table.”

For US-based buyers, add: a /do-not-sell/ page wired to your CCPA/CPRA flow, a DMCA designated agent contact if you publish UGC, GPC honoured at the JS level. For UK-based buyers, add: a footer block satisfying Companies Act 2006 §82.

A buyer evaluating a $59 kit and a $200 kit on aesthetics alone is comparing the wrong thing. The audit checklist above is what determines whether either kit can actually ship to a customer base that includes anyone in regulated geographies, which today is most of the addressable market for a SaaS.

A six-step audit you can run on any kit before you buy

If you are shortlisting a Next.js kit and you will be deploying anywhere in EU, UK, or California:

  1. Inspect the demo for legal pages. Visit <demo>/privacy/, <demo>/terms/, <demo>/cookie-policy/, <demo>/accessibility/, <demo>/dmca/, <demo>/do-not-sell/. Any that 404 are absent in the kit.
  2. Inspect the demo’s cookie banner. Open in a private window in a fresh session. If Reject all is smaller, less prominent, or hidden behind a Customise link, the kit fails the parity check.
  3. Test GPC honouring. Open the demo in Brave, or Firefox with Sec-GPC: 1 enabled. The cookie banner should not appear. Non-essential cookies should not be set.
  4. Check for an AI disclosure.If the kit has any AI surface (chat, playground, agent, generation), view the page source before JS hydration completes. Look for a server-rendered string like “AI-generated” or “interacting with an AI.” The EU AI Act requires the disclosure to be clear at or before first interaction; a server-rendered label is the most robust way to guarantee that, whereas one that only appears after JS executes is easy to miss or break.
  5. Inspect the footer for a registered-entity block. A real Companies Act §82 block names a company, a registration number, and a registered office. A placeholder like “Acme Inc · San Francisco” is what most kits ship, and you will have to wire your real values yourself.
  6. Ask the vendor for a per-release accessibility report. If they have one, you have found a kit that knows its buyer might be subject to procurement. If they do not, the burden of building one falls on you before you can pass a procurement review.

The buyer is the compliant party

Important caveat, and one most kit vendors should be clearer about than they are. A kit ships the structural wiring. It does not ship legal opinions. The buyer fills in real entity values, confirms wording with their own counsel, registers a real DMCA agent with the US Copyright Office if they publish UGC, and signs off on the deployment. The vendor’s job is to make sure that when the buyer does all of that, they are not also rewriting the architecture.

This is why the audit above is structural (“does the kit ship a /dmca/page that pulls from a config block?”) rather than substantive (“does the kit’s privacy policy hold up in court?”). The structural question is answerable in two minutes. The substantive question requires your lawyer.

What is at stake when it is missing

The kit market is mature enough that price-by-feature comparisons make most kits look interchangeable. The compliance scaffolding is the thing that decides whether the kit ships ready to deploy commercially, or ships beautifully and accrues hidden retrofit cost.

That hidden cost only becomes visible when:

  • You sign your first enterprise customer and their procurement asks for a VPAT
  • An EU user submits a DSAR and you have no endpoint to handle it
  • A California regulator asks how you honour GPC
  • A UK customer’s lawyer asks where your Companies Act §82 footer block lives
  • Your accessibility statement gets requested and you realise you do not have one

At that point you are three months into your deployment, your codebase has accumulated customer-specific changes, and retrofitting a compliance scaffold becomes the 2-4 week engineering project Deque benchmarked. At the $59 price tier, that cost dwarfs the original purchase by an order of magnitude.

The procurement audit is not going away

EAA enforcement is ramping through 2026. State-privacy laws in the US are multiplying: a growing number of US states have CCPA-style regimes, and the trend is not reversing. The EU AI Act applies to any AI surface that touches an EU user, which today is most SaaS. Companies Act §82 has been law in the UK since 2006 and is increasingly checked by enterprise buyers.

A kit that ships structural compliance scaffolding shifts the buyer’s deployment timeline from “I will figure out compliance later” to “the kit already handles the structural layer; my counsel just needs to sign off on the wording.”

That is the difference. It is not about the kit being better. It is about the buyer’s first 90 days being a product rollout instead of a compliance retrofit.

Last updated: 2 June 2026. The regulations cited above were verified against their respective official sources at time of writing. Confirm current requirements with your legal counsel before deploying.