Use cases
One platform, every team.
What people actually build with code-anything — by the industry they work in and by the job they do. Every one of them starts as a sentence and ends as a hosted app with a real database behind it.
six industries · six roles · one build path
Start here
What a use case means on this site
A short orientation before the list — what these pages are, how to pick the one that matches your situation, and what stays the same no matter which you land on.
A use case here is not a plan, an edition or a bundle you buy. It is a worked answer to the question people actually arrive with: what would I build with this, in my situation? A feature list cannot answer that. Knowing that the Postgres data layer is written for you is only useful once somebody says out loud that it means the shared spreadsheet with the colour-coded statuses becomes a real request queue with owners, an audit trail and an email that goes out on its own.
So each page below takes one position — an industry, or a job — and does four things: names the applications people in that position genuinely need, explains which parts of the platform carry them, sets out what you get that you would otherwise have had to build or buy, and answers the questions that come up before anyone commits. The applications differ enormously. The path to them does not: describe it, scope it in chat, review the blueprint, build, refine, publish.
How to pick the one that fits you
There are two axes, and most people sit on both. By industry is organised around the kind of business you are in and the software that business tends to need — an intake form and a booking page look very different in a wellness practice and in a retail shop, even though the mechanics underneath are the same. By role is organised around the job you personally do and the work you are trying to get off your plate — a product manager and an operations lead can work in the same company and need almost nothing in common.
If you are choosing what to build, start with your industry. If you are choosing what to stop doing by hand, start with your role. If neither list names your situation exactly, read the closest one anyway: the shapes repeat far more than the labels suggest, and everything these apps have in common applies whatever you call yours.
Who these pages are for
They are written for two readers at once. If you do not write code, the examples and the benefits are the part to read — they describe what the application does and what you no longer have to arrange yourself, in plain language. If you do write code, the detail is still there: what the agent writes for you, where a change is verified, what lands in your repository. The developer productivity page is written for you specifically, and the capabilities section carries the mechanism behind every claim made here.
What is on each page
Every use-case page follows the same structure, so you always know where to look. An overview explaining why the platform fits that situation; a set of example applications you could build, each one specific rather than aspirational; the advantages that matter for that particular kind of work; a long FAQ covering the objections and the boundaries, including the things it is not for; and links to the neighbouring use cases, capabilities and worked examples. If you would rather see the whole flow in one piece first, the platform overview walks it end to end and the docs take you through it step by step.
By industry
Built for your space
Six industries, and the applications each one keeps needing — from internal tooling to storefronts, classrooms to client bookings.
Industries do not differ much in the mechanics of the software they need — almost everything is records, screens, permissions and a message sent at the right moment. They differ enormously in which records, which moment and how much the details matter. A wellness practice needs a deposit taken at booking and an intake form whose answers stay behind a login. A retail shop needs a catalog that is data rather than markup so stock can drive what is shown. A school needs a project a student can publish and put in a portfolio, on a lab machine nobody is allowed to install software on.
These six pages are the industries where that translation is worth writing down. Each one is specific about the applications, honest about the boundaries — the health and wellness page is explicit that this is not for clinical or regulated medical use, and the finance page that it is internal tooling rather than a regulated platform — and links to the capability that carries the part you care about.
Productivity
Turn the spreadsheet everyone hates into a real app. Describe the internal tool you need and code-anything builds it, hosts it, and wires up the database behind it.
ExploreEducation
Educators and students can turn an idea into a working app without writing code. Describe a course portal, a quiz, or a class project and watch it come to life.
ExploreEntertainment
Spin up the site or app your audience needs before the moment passes. Event pages, fan hubs, and community tools from a single description.
ExploreHealth & wellness
Booking pages, intake forms, and client portals for coaches, studios, and wellness practices — described in plain English, hosted in minutes.
ExploreE-commerce & retail
Describe your shop and code-anything builds the catalog, the checkout, and the order dashboard — with the Stripe payment code written in, against your own Stripe account.
ExploreFinance
Budget trackers, expense tools, and internal finance dashboards described in plain English and hosted with a managed database behind them.
ExploreBy role
Built for your job
Six roles, and the work each one is trying to get off its plate — prototypes, workflows, campaign pages, people processes, chores in a codebase, and dashboards.
The role pages start from a different question: not what should exist, but what is currently costing you time that it should not. For a product manager that is the gap between a spec and something a user can click, where every argument goes to die. For an operations lead it is the process that is too specific for off-the-shelf software and too small for the roadmap, so it lives in a spreadsheet and a person’s memory. For a marketer it is a page that has to exist before the send goes out. For an analyst it is the chart that never became a thing anyone could open.
One of these pages is deliberately different. Developer productivity is not about building from a prompt at all — it is about connecting a repository you already have and getting the chores back as reviewed pull requests, edited in an isolated sandbox clone with typecheck, tests and a build already run. If you are the engineer everyone else in this list would otherwise be queueing behind, start there.
Product Management
Go from a written idea to a clickable, working prototype in minutes — then keep refining it until it is something your team can actually use.
ExploreOperations
Replace the manual, copy-paste workflows your team runs on with real apps — request queues, trackers, and dashboards you can build yourself.
ExploreMarketing & Sales
Launch a campaign landing page, a lead form, or a sales tool the day you need it — with email and payments wired in, no dev ticket required.
ExploreHR & Recruitment
Applicant trackers, onboarding portals, and internal HR tools described in plain English — gated with sign-in and backed by a real database.
ExploreDeveloper Productivity
Connect a GitHub repo and let code-anything do the grunt work — chores, fixes, and migrations land as reviewed pull requests you approve.
ExploreBusiness Intelligence
Turn the numbers your business runs on into shareable, hosted dashboards — described in plain English and backed by a real database.
ExploreThe common ground
What every one of these apps has in common
Twelve very different use cases, four properties that hold across all of them. This is the part that does not change when your situation does.
A real codebase
Not a page in a builder. Every project owns actual files in an editor you can open, which is why a tool that starts as a prototype can keep growing instead of hitting a wall.
A pre-wired backend when it needs one
The Postgres data layer, sign-in, the sending code and — on the plans that include it — Stripe checkout are written into the project the moment the app calls for them, and left out when it does not. Connecting the accounts behind them is a step of its own.
A public address of its own
Go Live ships the app you have been previewing to Cloudflare hosting over HTTPS. There is no export step and no gap between the version you approved and the one visitors get.
A change that had to prove itself
Every build runs typecheck, tests, a production build and a runtime check inside an isolated sandbox, repairs what failed, and is held for review rather than accepted when it cannot get to green.
The mechanism behind each of these has its own page under capabilities, and the providers underneath are named on integrations.
Already handled
What you get whichever use case is yours
None of this is a task waiting on your side, and none of it is a separate product you assemble. It is what the platform does around whatever you happen to be building.
The stack and the pipeline
- Hand-rolling a data layer — the Postgres schema, its migrations and a vetted access layer are written in when your app stores data.
- Writing sign-in from scratch — the auth brick brings a session provider, a login form, a route guard and a profiles migration.
- Getting row-level security right — RLS is forced on every table, and the columns its policies filter on are indexed.
- Building payment plumbing — the checkout endpoint, the redirect and a signature-verified webhook are written in on the plans that include payments.
- Shuttling keys between dashboards — a connection attaches the provider account once and fills the keys it owns.
The safety net and the record
- Renting a server or writing a deploy pipeline — builds and hosting run on Cloudflare, HTTPS by default.
- Wiring CI to gate a change — typecheck, tests and a production build run in an isolated sandbox first.
- Keeping a manual changelog — Repository → Features lists what exists and whether the last build verified it.
- Inventing a backup plan for a bad build — every build is checkpointed and the version history can be rewound.
- Installing anything — the editor, preview, database and deploys all live in a browser tab.
Payments, connected GitHub repositories, continuous monitoring and custom domains belong to the paid plans — see pricing for exactly where each one starts.
The path
How a use case becomes a running app
The same seven stages whether you are building a booking page, an applicant tracker or a KPI dashboard. Here is what you do at each one, and what the product does back.
The thing worth understanding before you start is that nothing changes shape as you move along this path. The app in the preview is the app that ships — there is no export, no build configuration to reconcile, and no moment where a prototype has to be rebuilt as “the real one”. That is also why a use case that starts as an experiment can keep going: the same project that validated an idea can be the one you publish, and on the plans that support it, the one you later connect to a GitHub repository so changes arrive as pull requests.
| Stage | What you do | What happens |
|---|---|---|
| Describe it | Say what you need in plain language — the screens, the data, who uses it. | The agent starts a project and opens the scoping chat instead of guessing. |
| Answer the questions | Fill in what cannot be inferred: who signs in, what gets stored, whether money changes hands. | A blueprint fills in as you answer, naming each service and whether it is managed for you. |
| Choose how much effort | Pick a build quality — Prototype, Standard or Best — for how much checking and research the build should do. | The run is scoped to that choice, so a throwaway experiment does not cost like a launch. |
| Watch it build | Confirm, and read the terminal while the sandbox boots and the app assembles. | An isolated container holds the code and runs the dev server the Preview tab renders. |
| Refine it | Describe changes in chat, or arm element selection in Studio and click the thing you mean. | The preview keeps showing the last stable version while a build runs, then refreshes itself. |
| Check what got built | Read Repository → Features for the ledger of what exists and what the last build confirmed. | A passing build re-verifies every feature; a failing one flags what it touched. |
| Go Live | Publish from Repository → Deploy — and press the same control again to redeploy later. | The build ships to Cloudflare with a real HTTPS address, and every attempt joins the deploy history. |
The docs walk through this path step by step, including what to do when a stage does not go to plan.
Where to start
Start from the job, not the label
If the industry and role headings do not obviously describe you, find the sentence that does — each one points at the pages that carry it.
| If what you need is to… | Start here |
|---|---|
| Replace a spreadsheet a team runs on | Internal tools · Ops workflows |
| Take bookings and collect intake details | Health & wellness · Worked example |
| Sell something online | E-commerce & retail · How payments get wired |
| Launch a page for a campaign or an event | Marketing & sales · Events & community |
| Put a number in front of the business | Dashboards & analytics · Finance tooling |
| Test an idea before committing engineering to it | Product management · Prompt to app |
| Run a hiring or onboarding process properly | HR & recruitment · Approval workflows |
| Change a codebase you already have | Developer productivity · GitHub PR agent |
| Teach with it, or build a student project | Education · Start from a template |
Every one of these is the same build path — the pages differ in the examples, not in the mechanics.
FAQ
Questions about use cases
Index
Every use case, in one list
All twelve, industries first, then roles.
Your use case isn't listed? Describe it anyway.
If you can describe it, you can build it. Start free with one active project and watch it come together live.