Describe the system. Own the app.
One sentence becomes an architecture, a design and a deployed app, in accounts you own.
Capabilities
What Crited does today.
crited-1.5 on the free plan
Every workspace starts on Crited's own model, sized for light and middling work. The frontier models from both vendors are named in the picker, greyed until you upgrade - so you can see what you are choosing between before you pay for it.
Two vendors, split by the work
A paid workspace runs Anthropic, OpenAI, or both: the strong models where the output is code somebody maintains, quicker ones everywhere else. Which model handles a turn is a classifier's decision, logged against a baseline, not a menu you have to keep thinking about.
Take payments on your own Stripe account
A spec that declares payments compiles a checkout, a webhook and a payments table into your app. Your keys, your dashboard, your payouts. Crited never touches the money and never becomes the merchant of record.
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.
A landing that shows the product
The design arrives beside the diagram the moment the draft finishes, without a click. Its landing frames a still of your own first page in a browser window, on a ground that is not white, in a type pairing chosen for the product - the four things the best reference sites share, each a field the compiler reads.
The keys your architecture calls for
A project asks for exactly the keys its spec needs - a model key for an assistant, Stripe for payments, Resend, Slack or Notion when an integration names them - on the node that needs each, in the architecture. Pasted once, encrypted, written into your own Vercel on deploy, and never into a project that has no use for them.
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.
Edit that code without leaving
The hand-written half of your app opens in an editor here, with the agent beside it. Ask for a change and you see the result in the file with the changed lines marked, then accept or reject it. Every save is one commit to your own repository, authored as you - Crited stores no copy of the file.
Take payments on your own Stripe account
Declare what an app sells and it compiles a checkout, a webhook and a payments table into it. The account is yours: the money moves between Stripe and your customer, and the amount is resolved on your server from a price list fixed at build time, never taken from the browser.
Promote and roll back from the deploy screen
Every deploy is listed, and any earlier one can be put back in front of the public in a click. Promotion moves the alias and runs no SQL, so the screen tells you which schema version that deployment expects and whether your database is at it before you press anything. A rollback runs the compiler's own down migrations instead, and shows them first.
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. There is a leaderboard of what gets installed most, and you appear on it only if you choose a public name for it.
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, or onto ours
Your infrastructure, your data, your keys, by default: nothing runs on hosting we hold unless you choose it. Choose it and the app is served at a subdomain on ours, with a SQL export of your data one click away, and the same spec compiles into your own accounts whenever you want it to. Schema changes ship as numbered SQL migrations applied in order, each one reversible; destructive ones ask before they run.
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.
- 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.
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.