Project structure
Where application behavior, provider integrations, and operational tooling live.
apps/
web/ React product application
server/ Bun + Hono API, migrations, and domains
docs/ Fumadocs + Next.js documentation site
packages/
contracts/ Shared Zod schemas and inferred types
billing/ Provider-neutral billing contract and adapters
email/ React Email source templates
create-app/ Buyer scaffold and branding workflow
agent-eval/ Outcome evaluation and evidence harness
agent-context/ Local read-only documentation MCP server
tsconfig/ Shared TypeScript policy
agent-tooling/
skills/ Optional general coding-agent workflows
docs/ Canonical product and operating documentation
infra/ OpenTofu bootstrap, modules, roots, locks, and tests
e2e/ Playwright browser and API boundary coverage
scripts/ Deployment, release, and repository verification
.github/ CI, cloud release, and source release workflowsThe studio source checkout may also contain seller-only landing/ and operations/ directories.
They are excluded from generated buyer repositories and are not application runtime dependencies.
Domain ownership
Each server domain follows the same route → service → repository path. Routes map HTTP and session state, services own policy and transactions, and repositories own parameterized SQL. The web app consumes the shared contracts rather than recreating API types by hand.
Use this structure as a map, not a restriction on product language. Add product-specific capability inside its own domain/module instead of folding it into generic files.
Keep the flow directional
Contracts describe the wire format. Routes map HTTP. Services own policy. Repositories own SQL. That separation makes ownership and failure behavior discoverable for people and coding agents.
Read Architecture for boundaries and production topology, or jump to Build your first feature for the extension workflow.