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.

Architecture
  • serviceauth
  • tablebookings
  • endpointcreate_booking
  • externalstripe
  • modulenotifications
Compiled output
  • 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.

Illustration of the shape of a project — nodes on the canvas, and the files compiled from them.

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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

Start a project