Proven by machine before you ever see it.
Every one of the 800 starter stacks on this site was compiled, migrated against a live database and connection-tested before publication, most recently on 2026-08-23, against exact pinned versions of Next.js, Better Auth and Drizzle.
It is architecturally impossible to serve an unverified snippet.
Every page reads pre-verified, pre-rendered text from our matrix database. Nothing is composed or checked when you load the page: the checking happens ahead of time, per stack, and a combination that fails simply has no page.
What happens before a page exists
the harness runs this per cell, off the request path, and writes the verdict to the matrix
Per-artifact verification
Each artifact is checked on its own terms, and each check has a failure mode that costs us a page rather than costing you an afternoon.
Type-checked against the actual installed SDK versions. If an API does not match the current release it fails, and we fix it before it ships.
Applied to a disposable Postgres or MySQL database. We assert the tables actually materialize, with the columns, relations and indexes the schema claims. A migration that parses but does not apply is a failure, not a warning.
Each deploy target's DB client (serverless pooled, long-running Node, edge HTTP driver) is load-tested with concurrent queries against a real database.
Billing and identity handlers are replayed against a live database to prove idempotency: a duplicate delivery yields one subscription, not two, and an out-of-order event cannot overwrite newer state.
Composed, never interpolated
A stack page is not a template with your framework's name substituted into it. Each axis (framework, database, auth provider, app schema, email provider) is a maintained code fragment, and a combination is those fragments composed into one program that then has to compile as a whole. That is why a broken pairing fails loudly at build time instead of producing plausible-looking code that does not run. It is also why the matrix has holes: a combination we cannot compile has no page rather than an unverified one.
Why the versions are pinned exactly
Every upstream dependency is pinned to an exact version, never a caret range and never latest. The pin is the claim: “verified against this” only means something if “this” is one version.
A floating range re-resolved during an unrelated install, moved Better Auth from 1.6.29 to 1.7.1, and broke signup on every stack that used it. Moving a pin is now a deliberate act: we ask the registry what changed, bump the pin, and re-run the whole sweep against it.
Two freshness signals
A verified config can go stale two ways, and watching only one of them is how a directory quietly rots.
A fragment we maintain gets edited. Tracked by content hash, because the upstream version has not moved and a version check would see nothing.
An upstream package ships a new version under static code of ours. Tracked by version, because the hash has not moved and a hash check would see nothing.
We watch both and re-verify when either moves. That maintenance is the product.
What the badge means
Compiled, migrated, and connection-load-tested against the listed versions on the listed date.
An upstream moved and we are re-checking. We show the last-known-good in the meantime rather than anything unproven.
What we do not claim
Verification is a compile-and-migrate proof, not an audit of your product. We prove the code we publish builds, applies and connects against the pinned versions on the stated date. We do not review your business logic, your access rules, or the edits you make after you download the kit. The guarantee stops at your first change.