How we test blueprints

The short version

A blueprint is marked build-tested only when an AI builder was given nothing but the blueprint, followed its phase prompts in order, and every acceptance check in the blueprint was then verified in a real browser. Each build-tested page shows four numbers: acceptance checks passed, automated tests in the build, spec gaps the build exposed, and build phases. It also lists what was not tested.

Anything less is labelled as what it is. A blueprint with a working demo but no independent build test says so on its page.

Why test a spec at all

Most "build an app with AI" advice stops at the prompt. A prompt that produces something that looks right is easy. A prompt that produces software a team can rely on is not: the hard parts are the rules nobody wrote down, such as who can approve what, what happens when someone is on holiday, or how a refund changes a commission that has already been paid.

The only way to find those holes is to build from the spec and check the result. Every gap the build exposes is fixed in the published spec, so the next team does not hit it.

The process

1. The blueprint is the only input

The builder receives the blueprint as a single Markdown file, exactly as a reader would download it. It does not see our demo code, earlier drafts or notes. The blueprint's build plan splits the work into phases; each phase is a prompt that ends with "list what you built and anything in the spec you had to interpret".

2. Phases are built in order

The builder sends the Phase 1 prompt, builds only that, and records what it had to interpret. It does not build ahead. Then Phase 2, and so on. This mirrors how a person would use the blueprint, and it is where vague specs fall apart: a rule that seems obvious in Phase 2 turns out to need a field that Phase 1 never created.

3. Acceptance checks run in a real browser

Every phase in a blueprint ends with acceptance checks, for example: "Signed in as Ana while Maya's step is active, there is no Approve button and a direct API call is refused." Each check is written as an automated browser script (Playwright driving Chromium) that clicks through the app as the named person and asserts on what is visible on screen. Where a check says the server must refuse something, the script also makes the request directly.

After the last phase, the database is reset to the seed data and every check from every phase is run again in one pass. Only that final run counts.

4. Gaps go back into the spec

When the builder has to guess, because the spec is silent, ambiguous or contradicts itself, that is recorded as a spec gap with the exact wording that would have prevented it. The gap is then fixed in the published blueprint and listed in its build notes. A blueprint with zero gaps found is rare; a blueprint whose gaps are listed is more trustworthy than one that claims none.

5. Results are published as they are

The page shows the checks that passed out of the total. If a check could not be verified, it is not counted. Build notes list what was not tested.

What we do not test

These are listed on each build-tested page, and they are the same for most blueprints:

• Production sign-in. Builds use a development-only "sign in as" switcher to test as different people. Google sign-in or your platform's own auth needs to be set up and checked in your environment.
• Live third-party services. Email, Slack and calendar integrations are built as the spec describes and tested through an outbox or with correctly signed test requests, not by delivering real messages.
• Hosting at scale. Test builds run on a single server with SQLite. For a hosted deployment, use your platform's managed database with the same schema.
• Every AI builder. Builds are run with Claude. The blueprints are written to be builder-agnostic, but a different builder may interpret the same words differently. The acceptance checks are how you find out.

Verification levels on this site

The interactive demos

Most blueprints include a demo you can open in your browser. The demos run entirely in your browser with fictional sample data, simulate sign-in with a person switcher and simulate time with a clock control. They show how the tool behaves; they are not the production build and they do not send email or store anything on a server.

Corrections

If you build from a blueprint and something in it is wrong or unclear, that is a spec gap. Tell us through the request form on the home page and we will fix the blueprint and credit the finding in its build notes.