Proof 01
Setup readiness is visible before launch
The `/setup` page and `npm run setup:check` show which integrations are configured without printing secret values.
Day 0 proof
Toolbound starts from working commercial rails, not a blank promise.
Before a founder asks an agent to customise the product, Toolbound proves the boring launch path: setup checks, checkout, webhook persistence, transactional email, deploy docs, and a handoff prompt.
Proof 02
Checkout is a real commercial path
The buy page is connected to a one-time founder licence flow with Stripe Checkout, signed webhook handling, and purchase metadata.
Proof 03
Agent handoff is first-class
The `/handoff` page gives Claude, Codex, Cursor, or Windsurf a one-paste prompt with product context, safe edit zones, and verification commands.
visual evidence
Three screenshots that matter before customisation.
Setup dashboard
Shows integration readiness without exposing secret values.
Checkout page
Shows the founder licence purchase path before feature work.
Agent handoff
Shows the one-paste context an agent receives before edits.
Verification contract
What should pass before launch?
- npm run setup:check confirms required files and connected services.
- npm run test verifies business logic and discovery metadata contracts.
- npm run lint keeps generated edits reviewable.
- npm run build confirms production routes, metadata, and discovery files.
- Cloudflare or host checks confirm robots, sitemap, llms.txt, ai.txt, and headers.
- Stripe, Resend, and Postgres are smoke-tested with live or test credentials before selling.
FAQ
Common questions
What does Day 0 proof mean for a SaaS boilerplate?
It means the boring commercial path is already working before you customise anything: setup checks pass, Stripe Checkout completes, the signed webhook persists a purchase, Resend delivers email, and Postgres records are written.
Why does this matter before I add features?
Because a founder should be able to prove payments, email, persistence, and agent-safe customisation before promising a paid product to real users. Proof first means custom work starts from a known-good base.
How do I re-run the proof after a coding agent edits the repo?
Run the verification contract: npm run setup:check, npm run test, npm run lint, and npm run build, then smoke-test Stripe, Resend, and Postgres with test credentials before selling.