Platform
How it works, end to end.
Two paths share one platform: describe an app and publish it, or connect a repository and review a pull request. Both run on the same build sandbox, the same managed backend, and the same monitoring after launch.
Overview
What the code-anything platform is
An AI app builder that owns the whole distance between a sentence of plain English and software running on a real URL — including the parts nobody enjoys.
Most tools that write code stop at the code. You are handed a project folder and then left with the work that actually takes the time: standing up a database, wiring authentication, connecting an email provider, adding payments, configuring a build, buying hosting, pointing a domain, and then finding out days later that the deploy has been failing since Tuesday.
code-anything is built the other way round. The generated application arrives with that work already done in code — a Supabase data layer, sign-in, Stripe checkout and row-level security come out of a catalogue of vetted bricks rather than being written afresh each time — running in an isolated build sandbox, deployable to Cloudflare in one click, and health-checked continuously once it is live. The prompt is the part you see; the platform is everything underneath it that keeps the result usable a month later.
There are two ways in, and they exist because two very different people arrive with two very different starting points. If you have an idea, you take the create path: describe it, watch it build, publish it. If you already have a codebase, you take the edit path: connect the repository, describe the change, review the pull request. Everything below the two paths — the sandbox, the managed services, the verification, the monitoring — is shared, and each piece has its own page in the capabilities index if you want the detail rather than the tour.
Who it is for
The platform is deliberately usable without engineering skill, and deliberately not insulting to people who have it. Both of those are design constraints, not marketing.
Founders and operators with an idea
You know exactly what the product should do and have no interest in learning a framework to find out whether it works. You describe it, and you get something real enough to show a customer.
Teams without a spare engineer
Marketing, ops and support all have internal tools they would build if a developer were free. Here the tool gets built, hosted and monitored without taking anyone off the roadmap.
Developers with a backlog
You already have a repository and a list of changes nobody wants to start. Point the agent at the repo, describe the change, and review a pull request instead of writing it.
What you need before you start
An account and a browser. That is the whole list for the create path — the workspace, editor, preview, database and deploys are all hosted, so nothing is installed and the same project follows you to whichever machine you sign in from. The edit path adds one thing: a GitHub repository you are allowed to authorize access to. There is no credit card required to start: the free tier covers prompt-to-preview with a managed database, auth and email included, while custom domains, Stripe payments, connected repositories and continuous monitoring sit on the paid plans — the pricing page lists exactly what each tier includes.
Choosing a path
Two paths, one platform — which one is yours?
They are not tiers, and one is not the beginner version of the other. They differ only in what you start with and what you get handed back.
| Create — prompt to app | Edit — repo to pull request | |
|---|---|---|
| You start with | An idea, described in a sentence or two | An existing GitHub repository |
| The agent produces | A complete, running application | A change to code you already own |
| Where work happens | A fresh build sandbox with the backend code written in | An isolated clone of your repository |
| You get back | A live preview you can publish with Go Live | A pull request with passing checks |
| How you iterate | Chat, click-to-target editing, screenshots, template and palette swaps | Follow-up prompts and review comments on the PR |
| Who has to approve | You, by pressing Go Live | You, by merging the pull request |
| Best when | The thing does not exist yet and you want it in front of someone today | The thing exists, the change is clear, and nobody has time to start it |
Nothing stops you using both — a project created here can be connected to a repository and worked on the same way afterwards.
The create path
Prompt → live preview → Go Live
Six steps from a sentence to a hosted URL. Three of them are yours; the rest happen while you watch.
Describe the app in plain Englishyou
One or two sentences is a valid spec: what it is, who uses it, what it has to do. You can attach a screenshot or reference image when you already know how it should look, and keep talking until the brief matches what is in your head.
The agent plans before it writesagent
Rather than emitting files immediately, it works out the screens, the data model and the flows first. That plan is visible to you, so a wrong assumption gets corrected in a sentence instead of surfacing three hundred lines later.
A sandbox starts and the bricks go inautomatic
An isolated build sandbox starts, and anything the plan calls for that the brick catalogue already covers — sign-in, checkout, the data layer, routing, row-level security — is written in rather than composed from scratch. There are no accounts to create and no keys to paste before you see something running.
The build renders as a live previewautomatic
Pages appear as they are generated. This is the running application, not a mockup or a design file — you can click through it, submit its forms and see the rows land in the database.
You iterate in whichever way is fastestyou
Ask for a change in chat, click the exact element in the preview to target an edit precisely, or drop in a screenshot to match a look. Swapping the whole template or recolouring with a different palette are single steps, not rebuilds.
Go Live publishes to a real URLyou
One click deploys the app to a hosted, SSL-secured URL on Cloudflare, ready to point a custom domain at. Nothing publishes until you decide it should.
What makes the preview worth trusting
The reason a preview here can be published in one click is that it was never a preview in the design-tool sense. It is the application, executing in a sandbox, running the same Postgres schema and the same auth, email and payment code it will run once it is live. Going live changes where it runs, not what it is — which is why there is no second, separate “now make it production-ready” phase to dread. The mechanics of both halves are broken out under live preview and point-and-edit and shipping to a real URL.
How editing actually feels
Conversational editing is the default, and it is the right tool for structural change: add a screen, change what a form collects, make the pricing table monthly and annual. For surgical change, clicking the element you mean in the preview removes the guesswork of describing which of four headings you were talking about. And when you already have a reference — a competitor’s layout, a slide, a sketch — an image gets you closer in one step than three paragraphs of description would.
The edit path
Repo → sandbox → verify → reviewed pull request
The agent reads your codebase the way a careful contributor would, works somewhere it cannot break anything, proves the change builds, and then asks for review.
Connect the GitHub repositoryyou
Authorize access to the repo you want worked in. Nothing is cloned to your machine and nothing is installed — the workspace is hosted, so the repository is reachable from any browser you sign in from.
The codebase is indexedagent
Indexing is semantic and symbol-aware rather than plain text search, so the agent can follow which module owns a behaviour, where a symbol is defined and what calls it — the reading a developer does before touching anything.
You describe the changeyou
A feature, a fix, a refactor, a dependency bump. The more precisely the outcome is stated — including what must not change — the closer the first attempt lands.
The work happens in a sandbox cloneautomatic
Edits are made against an isolated clone, never your working repository. A run that goes wrong is discarded with the sandbox, so a bad attempt costs you nothing but the time to say so.
The agent verifies its own workagent
Your typecheck, your test suite and your build command are run against the change before you ever look at it. Failures are the agent’s problem to fix inside the sandbox, so review starts from a green baseline instead of a broken branch.
A pull request arrives for reviewyou
The result is an ordinary pull request with passing checks. Read the diff, comment, ask for tweaks, merge or close it. Your repository only ever changes through that PR — nothing is pushed behind your back.
Why the index matters more than the model
Most disappointing AI edits are not failures of writing — they are failures of reading. An agent that greps for a string will happily change the one occurrence it found and miss the four that matter. Indexing your repository semantically and by symbol is what lets the agent answer the questions a reviewer will ask: where is this defined, who calls it, what breaks if it changes shape.
Why nothing is pushed for you
The pull request is not a formality — it is the safety model. Work happens in a clone, so a bad run is thrown away with the sandbox rather than reverted out of your history. The checks run before you are asked to look, so your attention is spent on whether the change is right rather than whether it compiles. And the merge button stays where it has always been. The two halves of that promise have pages of their own: semantic, symbol-aware code intelligence for the reading, and sandbox verification for the typecheck, test and build gate — with the delivery mechanism described under the GitHub pull-request agent. How repository access is handled is set out on the security page.
$ connect github.com/acme/storefront
✓ indexed 1,284 files · 96 symbols
$ "add dark mode across the app"
✓ edited 14 files in a sandbox clone
✓ typecheck · tests · build — all green
→ opened PR #481 "Add dark mode"The foundation
The backend every project is given
Named, real services, reached through pre-written code that goes in with the first build rather than being offered as an upsell after the demo.
A real data layer
Postgres on Supabase, reached through a vetted data-access brick written into the project — a service-role helper on the server, an RLS-gated client in the browser. Tables, relations and migrations are generated with the app, so the preview reads and writes actual rows rather than mock data.
Authentication and sessions
The auth brick arrives whole rather than being typed out again: a session provider and useUser() hook, an email sign-in and sign-up form, a route guard, sign-out, and a migration that gives every new user a profile row under row-level security.
Transactional email
Sending code for confirmations, password flows, receipts and notifications is generated against Resend, server-side so keys never reach the browser. This is the one piece with no brick behind it: you bring the Resend key and verify the domain mail leaves from.
Stripe payments
The payments brick writes the Checkout Session endpoint, the client redirect and a signature-verified webhook — against your own Stripe account, so a product that needs to charge for something charges for it in the same build, and the money goes to you.
Hosting on Cloudflare
Builds and deploys run on Cloudflare and serve from its global edge with SSL and custom domain support — the same infrastructure serving this page.
The point of naming these is that they are ordinary, boring, well-understood services rather than a bespoke runtime you would have to learn and could never leave. A generated app talks to Postgres the way any application talks to Postgres. What the platform supplies is the code between your app and them — vetted once, inserted rather than re-derived — and the accounts those services run on stay ordinary accounts you can connect, keep or take elsewhere. That layer is described in more depth under the managed backend, and if your product later needs to reach something beyond the defaults — REST endpoints and webhooks, OAuth sign-in, analytics, a custom domain — the integrations directory is where to check what connects and what connecting it gives you. The agent doing the writing is Gemini, GLM and Mercury.
Design
Starting points, so the first build already looks like something
A blank page is the slowest way to begin. Templates, palettes and elements give the agent a concrete brief to build from.
95 website and app templates
Hand-built starting points rather than screenshots — pick one and the build begins from real code, then every section, colour and line of it becomes yours to change by asking.
22 contrast-checked palettes
Curated colour sets that recolour a whole app in a click, so choosing a look does not mean nudging hex codes one component at a time.
3,794 drop-in elements
Animated buttons, cards, loaders and form pieces the agent can place directly into your app when you name the one you want.
None of these lock anything in. A template is real code the build starts from, not a skin applied at the end, so asking for a different section layout is a normal change rather than an escape from a theme. Browse the full set in the template gallery, compare colour sets on the palettes pages, or see what other people build with them under use cases by industry and role — internal tools, storefronts, booking flows, dashboards and the rest.
Division of labour
What is automated, and what stays under your control
The rule the platform is designed around: everything reversible is automated, and everything irreversible waits for a person.
| Stage | Handled for you | Your decision |
|---|---|---|
| Planning | The agent drafts the screens, data model and approach | Redirect it in a sentence before it writes anything |
| Infrastructure | The data, auth, payments and security code is written in from vetted bricks; hosting runs on Cloudflare | Whether the project needs them, which accounts to connect, and what it stores |
| Writing code | The agent writes and edits inside a sandbox | What good looks like, stated in the brief |
| Verification | Typecheck, tests and build run automatically | What your checks actually assert |
| Design | Templates and palettes are applied consistently across the app | Which template, which palette, and the final art direction |
| Merging | The pull request is opened with results attached | Reading the diff and pressing merge |
| Publishing | The build and deploy pipeline runs | Pressing Go Live, and pointing your domain |
| Recovery | Health checks and alerts run continuously | Choosing to roll back |
No merge, no deploy and no domain change happens without an explicit action from you.
After launch
Monitoring, alerts and rollback
Shipping is the start of the interesting part. The platform keeps watching so that a broken deploy is something you are told about rather than something a customer discovers.
Continuous health checks
Builds, deploys and live previews are checked continuously rather than only when you happen to open the tab, so a project that stopped serving is noticed as a state and not as a surprise.
Alerts when something breaks
A failed build or a failed deploy raises an alert instead of sitting silently in a log you were never going to read.
One live view of every project
Status for each app you run in one place — what is deployed, what is building and what needs attention — rather than a dashboard per provider.
One-click version restore
When a change turns out to be wrong in production, going back to the last good version is a click, not an incident with a runbook.
This is the part that separates a demo from a product, and it is why the platform does not end at deploy. The full behaviour — what is checked, what raises an alert and how a rollback works — is written up under workspace monitoring.
Your side of the deal
What the platform costs you in effort
Honest accounting: the work does not disappear, it changes shape. You spend less time typing and more time deciding.
Saying what you actually want
The single largest input is a clear description. The agent will make a decision for every detail you leave out, and correcting those decisions afterwards costs more than stating them up front.
Reading the result
On the create path that means clicking through the preview; on the edit path it means reading the diff in the pull request. Automated checks prove the code runs, not that it does the right thing.
Owning the judgement calls
What counts as done, what is safe to ship, who may see which data, and when to merge — these stay with you by design. The platform is built so that no irreversible step happens without a person choosing it.
In practice the rhythm is short: describe, look, correct. The correction loop is where the quality comes from, and it is fast precisely because the preview is real and the checks have already run. What you are trading away is the setup, the glue and the operational tail — not your judgement about the product.
Limits
Where the platform stops, and a human still wins
Every one of these is a real constraint rather than a coming-soon. Knowing them up front is what makes the rest dependable.
Vague prompts make vague apps
An underspecified brief is not rejected — it is interpreted. If the outcome matters, describe the edge cases, the roles and the rules rather than only the happy path.
Verification is as strong as your checks
On the edit path the agent runs the checks your repository already defines. A codebase with thin tests gets a thinner guarantee, and the pull-request review matters more.
Big changes are better split up
A sweeping rewrite described in one sentence is harder to review than the same work requested as a handful of smaller, self-contained changes — the same rule that applies to a human contributor.
Taste and compliance stay yours
Generated design is a strong starting point, and a template or palette gets you further, but the last ten percent of art direction is a human decision — as are licensing, content and any regulatory obligation your product carries.
If you are weighing this against another tool — or against writing it yourself — the comparison pages against Lovable, v0, Bolt and Cursor are written the same way, including the situations where a different product is the better answer.
The alternative
Wiring it yourself vs building it here
Not a question of whether you could do each of these. A question of how many of them you want to do again for the next idea.
| What every real app needs | Wiring it yourself | On code-anything |
|---|---|---|
| Project scaffold | Choose a stack, scaffold it, configure tooling | Generated from your description, or from a template |
| Database | Pick a client, write the CRUD, manage connection and schema | Postgres schema, migrations and a vetted access layer written into the project |
| Authentication | Pick a provider, wire sign-in, handle sessions | The auth brick dropped in whole — provider, form, route guard, profile migration |
| Database security | Write RLS policies by hand, then index what they filter on | RLS forced on every table and the matching indexes, from one brick |
| Transactional email | Set up a provider, verify a domain, template the mail | Your Resend key and domain; the sending code and templates generated around them |
| Payments | Integrate Stripe, handle checkout and webhooks | Checkout endpoint, redirect and signed webhook written in, on your own Stripe account |
| Hosting and TLS | Choose a host, configure the build, set up SSL and a domain | One-click deploy to Cloudflare with SSL and custom domains |
| Checks on every change | Write and maintain a CI pipeline | Typecheck, tests and build run before the change reaches you |
| Knowing it is still up | Add monitoring, alerting and a rollback procedure | Continuous health checks, alerts and one-click version restore |
The generated project is ordinary software on ordinary services, which is the point. The platform removes the assembly, not the ownership. If you would like the step-by-step version of either path with screenshots of the actual flow, that lives in the documentation.
Keep reading
Where to go next
Six directions from here, depending on what you still want to know.
Capabilities
Every capability on its own page — prompt to app, live preview, Go Live, managed backend, code intelligence, verification and monitoring.
ExploreIntegrations
Supabase, Stripe, Resend, GitHub, Cloudflare and the AI models written in by default — plus REST, webhooks, OAuth, analytics and custom domains.
ExploreTemplates
Browse the starting points, preview them full-screen, and see the palette each one ships with.
ExploreUse cases
What people build here, grouped by industry and by role, with the pattern behind each one.
ExploreComparisons
Honest side-by-sides with Lovable, v0, Bolt and Cursor — including when another tool fits better.
ExplorePricing
Plans, what the free tier includes, and what happens as a project grows.
ExploreFAQ
Questions about the platform
The things people ask before they start — answered without hedging.
- Nothing to install — the whole workspace runs in a browser tab
- Managed database, auth, email and payments included with every project
- Every change to an existing repository arrives as a pull request you merge
See it work on your idea.
Start free. Describe an app or connect a repo — the sandbox, the backend and the monitoring are already handled.