Early access
Architecture first, code second.
You shape the system on a canvas with an agent: modules, services, tables, endpoints and the edges between them. Crited compiles that structure into a Next.js and Supabase app, pushes it to your GitHub and deploys it into accounts you own. Same structure in, same app out, every time.
- serviceauth
- tablebookings
- endpointcreate_booking
- externalstripe
- modulenotifications
- app/api/bookings/route.ts
- app/(app)/bookings/page.tsx
- lib/bookings.ts
- supabase/migrations/0007_bookings.sql
Regenerated from the graph on every accepted change.
Capabilities
What Crited does today.
The canvas is the source
Nodes and edges are the project, not a picture of it. The agent proposes changes to that graph, you accept them, and every accepted change becomes a version you can diff against the one before.
Integrations read, they don't write
Crited reads Notion, Slack and GitHub, pulls candidate tasks out of the discussion, and flags which part of the architecture each one touches. Every suggestion waits for a person to accept or reject it — nothing is applied on its own.
Import an existing repository
Point Crited at a repo and it reads the code into a first-cut architecture: modules, services, tables and how they connect. A draft to correct, not a verdict.
A theme you approve is the theme that ships
Pick a theme and see it rendered by the compiler's own stylesheet, over your own screens — not a mock-up drawn alongside the build and free to drift from it. What you approve and what gets compiled are the same tokens.
Work from Cursor or Claude Code
Connect your editor over MCP and it reads the specification, proposes changes to it and previews the compiled migration before anything ships. Changes arrive as ordinary versions with an author, revertible like any other.
Your code, in your own repository
Every build is pushed to your GitHub as a single commit. Everything under src/custom/ stays yours: the compiler never reads it and never overwrites it, so hand-written code survives each rebuild.
Compliance documents compiled, not written
The data map, access matrix, retention rules and subprocessor list are derived from the same specification the app is built from, so they describe what is actually deployed and go visibly stale the moment it changes.
An assistant inside what you ship
Add a chat box grounded in your own records, with optional semantic search over them. It runs on your API key in your deployment and reads through the signed-in user's session, so it can never see more than that person could. Install the key through Crited, or add it in Vercel yourself and we never hold it.
Several agents at once
Run more than one agent in parallel, each in its own tab with its own context, so a long thread about one part of the system doesn't drag the rest of the project through it.
Model routing with the meter showing
Each kind of task is routed to a model picked for it — the strongest for architecture and code, the cheapest for bulk classification — and what a run costs is recorded and shown as it accrues.
Start from somebody's else's architecture
Install a published project as the starting point for your own, or publish one of yours. A template arrives as an ordinary specification you can edit and diverge from — not a locked scaffold you grow out of.
On the desktop as well as the web
A signed desktop build for macOS and Windows that updates itself, for when a long agent run should not depend on a browser tab staying open.
Deploys into your own Vercel and Supabase
Your infrastructure, your data, your keys — nothing runs on hosting we hold, and there is no lock-in to unwind later. Schema changes ship as numbered SQL migrations applied in order, each one reversible; destructive ones ask before they run. A domain can be bought from the deploy screen, on your own Vercel token into your own account, so the registration is yours and not a line on our invoice.
How it works
Five steps, in this order.
- 01
Describe the system, or import the repo you already have
Either way you end up looking at the same thing: an architecture graph you can argue with.
- 02
Shape it with the agent
Add nodes, redraw edges, reject the proposals you disagree with. Each accepted edit writes a new version of the spec.
- 03
Connect the places the work is discussed
Notion, Slack and GitHub feed a queue of candidate tasks, each tagged with the part of the system it touches, each waiting on your yes or no.
- 04
Generate the code
The compiler turns the current version into an app — routes, schema, migrations — from the graph, so the same version always produces the same output.
- 05
Deploy to your infrastructure
Crited pushes to your Vercel project and your Supabase database, applying migrations in order and leaving you a way back.
Start with one system.
Bring an idea or a repository you already have. You will need your own Vercel and Supabase accounts when it is time to deploy; there is no billing yet.