Your client-site stack doesn't scale past the third rebuild.
Every new engagement means re-solving schema, auth, and deploy from a blank folder. And the clients you're closest to are already asking why their site doesn't show up in ChatGPT.
AI Launch Kit is Apache 2.0. The Working Theory Labs team runs Sam Henry, Working Theory, and SalesSmyth on this same foundation — that dogfooding is why the schema registry and peer-surfaces architecture exist in their current shape.
Why does every client build start from zero?
Every client build starts from zero because the stack underneath it doesn't carry structure forward. A custom Next.js site solves schema, auth, and content types fresh each time; a WordPress build solves them through whatever plugin combination survived the last core update. Neither foundation accumulates work across engagements, so the agency re-pays the same setup tax on every project. On a custom Next.js build, the third engagement in a quarter re-solves what the first one already solved: content models, JSON-LD, form handling, deploy pipeline. On WordPress the tax shows up as plugin conflicts instead of senior-developer hours — a schema plugin, an FAQ plugin, and an AEO plugin that don't integrate and break on the next update. Either way, the agency's own margin absorbs the setup cost every time. The work that made the last site citable by AI search doesn't carry into the next one unless someone copies it by hand. A foundation removes that tax not by looking better, but by making schema, entity markup, and an agent-callable surface structural defaults instead of line items someone has to remember to build.
SaaS starter, closed builder, or custom Next.js — which is actually your stack?
Three defaults exist for a client-site foundation: a SaaS starter, a closed builder, or a custom Next.js build. None of the three were built to be read by AI search or called by agents. AI Launch Kit is the fourth option: an Apache 2.0 Next.js foundation with schema, MCP, and AEO scoring as defaults, not add-ons.
Typed schema registry + JSON-LD out of the box
MCP server + HTTP API with CI-enforced parity to the web UI
ailk audit CLI scores AEO structure pre-launch, in CI
Apache 2.0 — you own the codebase
Built for SMB marketing sites, not SaaS dashboards
60 typed page types ship in the registry — FAQ, glossary, entity, LocalBusiness — not a plugin stack.
What should a foundation for client sites actually do?
A foundation for client sites has to do five things. None are AILK-specific — all are structural prerequisites for a site that AI systems can read and act on. It has to be read correctly: the model should know what a page is about and which business it belongs to, without guessing. It has to work for non-human visitors. Agents now research on a buyer's behalf, and the foundation should expose itself to them as a first-class audience, not a degraded API. It has to surface its own gaps. AEO problems are silent — the site doesn't crash, it just stops getting cited. A foundation should catch structural gaps the way a linter catches type errors, in CI. It has to belong to the people running on it, since a foundation that locks the agency in shapes its roadmap around the lock-in, not the client's outcome. And it has to fit inside the engagement: an SMB site runs on a timeline of weeks, not quarters, and a foundation demanding a multi-month custom build breaks the economics before the first invoice.
AI Launch Kit: the open-source foundation built for this stack
AI Launch Kit (AILK) is the open-source website foundation for the agent-first internet. It's the substrate AI-search agencies and Next.js-native shops use to ship client sites that work for agents and humans from day one. Apache 2.0, full stop — not source-available, not gated after signup.
Apache 2.0, structurally complete
The clone you get today is the same foundation Pro and Launch Service run on. Paid tiers add capability (lead routing, managed deploys), never access.
Built for marketing sites, not SaaS dashboards
Case studies, FAQs, entity markup, and local-business identity are first-class page types, not hand-built content models.
Runs on itself
Same dogfooding noted above: we run our own brands on AILK and hit the schema and deploy problems first, before your clients do.
How do peer surfaces and agent-assisted scaffolding change the build?
Peer surfaces mean an agent gets the same capability a human gets, through a typed contract enforced in CI. Agent-assisted scaffolding means the setup work that used to require a senior developer is now a guided workflow, from create-ailk to a deployed site in days.
Peer surfaces, CI-enforced
Three apps in one repo: apps/web for humans, apps/mcp for agents, apps/api for programmatic callers. Parity between them is a CI test, not a hope.
A typed schema registry, 60 page types deep
Zod-validated frontmatter emits JSON-LD per page type (FAQ, glossary, entity, LocalBusiness) without a plugin stack to maintain.
ailk audit runs before launch and in CI
The same CLI that scores this site's structure runs against any client site, catching missing schema before the client asks why they're invisible.
Agent-assisted scaffolding, not a scaffolding script
create-ailk generates the three-app skeleton in one command. The .claude/ bundle ships eight skills: extract-design-from-reference, suggest-site-pages, scaffold-page, add-schema, audit-site, scaffold-auth, scaffold-commerce, provision-config. A Claude Code session does the setup work a senior developer used to own.
What does onboarding in a day and near-zero marginal cost per page mean for margin?
Onboarding a new hire, or a new agency partner, takes a day on AILK, not a week of tribal-knowledge handoff. The scaffolding workflow is the same whether it's the first site or the fiftieth — which is why the marginal cost of shipping one more page approaches zero.
The citation work compounds instead of restarting
Every page is already schema-structured, so campaign and content work lands and stays landed instead of re-fighting a plugin stack each engagement.
Onboard a new hire in a day
The scaffolding workflow (create-ailk plus the .claude/ skills bundle) is the same guided process whether it's someone's first AILK project or their fiftieth.
Marginal cost of a page approaches zero
Adding a service page next week is the same Claude Code session as the initial deploy. A citation gap gets a fix in a day, not a quarter.
Own the codebase, own the client relationship
Apache 2.0 means no platform takes a cut and no vendor reshapes your roadmap mid-engagement.
A two-week fixed-scope deploy, not a three-month custom build
Launch Service turns the setup work into a fixed-scope engagement, recovering the margin a custom build usually eats in week one.
Common questions from agencies standardizing their stack
How is this different from the custom Next.js stack we already build?
Same language, different starting point. A custom build re-solves schema, auth, and content types on every engagement. AILK ships a typed schema registry, an MCP server, and an audit CLI as defaults, so the parts that don't differentiate your work are already built — your team's Next.js fluency goes straight into the client-specific work.
Where's fleet management for a whole portfolio of client sites?
There's no separate tier. Fleet management, cross-site rollup, white-label, and per-seat licensing are planned as a future Enterprise multi-tenant entitlement, not shipped yet. At launch, agencies deliver on the OSS plus Pro, per-user, per-site.
You're pre-launch. Why commit our stack to this now?
The architecture is observable in the repo, not a slide deck: the schema registry, the CI parity test, and the audit CLI all run today. Apache 2.0 bounds the downside — if AILK doesn't gain traction, you keep the codebase and keep the client.
Is the OSS actually complete, or is it crippled to sell Pro?
Structurally complete, see above — paid tiers add capability, they never add access.
Ready to standardize your stack?
Clone the OSS and ship the next client site on it, or start a Pro trial if per-user seats fit how your team already works.