Blueprint
Web App
When people log in and the data belongs to them.
A site where people log in and the data belongs to them. Client portals, dashboards, internal tools with an outside face, SaaS.
The line between this and a marketing site is not complexity, it is state. The moment two people load the same page and should see different things, or somebody changes something and expects it to still be there tomorrow, you are building an app. That is what forces a database and a login, and everything else on this page follows from those two.
Web apps, not mobile apps. This runs in a browser.
Notice how much of the build layer is identical to the marketing website blueprint. Only the framework, the host, and the data layer change.
How I orchestrate the build
Editor
Where I sit. Claude Code runs inside it, so the work and the code are in one window.
Orchestration
Does the actual building. I describe the change, it writes it, I review it.
Building from my phone
Same project, away from the desk. Useful more often than it sounds.
Input (I don't type)
I talk, it types. Dictation that keeps up with a train of thought.
What it's built with
Framework
React with a server attached. An app needs to run code per request, which is the line a static site does not cross.
Styling
Same as every other build. Styles next to the markup, no separate stylesheet drifting out of sync.
Bot protection
Sits on signup. An open registration form is a magnet, and the damage is thousands of junk accounts in your database.
Logins
Email, magic links, or Google. Password handling is the thing you least want to write yourself, so I don't.
Where the code lives
The working copy
The real one. A directory in my projects folder on this computer, where the work actually happens.
Version control + what the deploy watches
Every version of every file, forever. Pushing here is what triggers a deploy.
Where the data lives
Database
Plain Postgres, not a proprietary store. Thirty years of tooling already understands it, which matters the day you need something it was not designed for.
Files and media
Anything that is a file rather than a record. Uploads, generated documents, images, video. Supabase has its own storage and it is the easier answer when a file needs the same permissions as the row that points at it. R2 wins on price and on egress once the files get big or get downloaded a lot.
Nightly backup
A dump of the database every night, held somewhere the app cannot reach, because a backup inside the thing you are backing up is not a backup. Uploaded files are a separate problem and belong wherever the files live.
Where it's hosted and how it deploys
Host / deploy
Built by the people who build Next.js. Watches GitHub, deploys on push, gives every branch a preview URL, and its own edge network is the CDN, which is why there is not a separate one on this page.
DNS + domains
DNS only here, pointing at Vercel. The domain staying with Cloudflare means moving hosts later is a DNS change rather than a migration.
Integrations
Transactional email
Password resets, invitations, notifications. The emails that must arrive within seconds or the app looks broken.
Legal policies
More necessary here than on a marketing site. The moment you have accounts and store personal data you need terms and a privacy policy that keep up with the law.
Payments
If it charges anyone. Subscriptions, invoices, and the customer portal, so nobody is writing billing logic from scratch.
The questions that come up
Fewer than the marketing site, because the decisions here are mostly technical and you have usually already made the big one by the time you are reading this. These are the ones worth settling before anything gets built.
- Q Why not just add a login to WordPress?
- It works right up until the app has real logic. Then you are writing an application inside a content management system, fighting its assumptions, and paying for plugins that each own a piece of your data model. The line is whether the thing is a site with a members area or software that happens to have pages. If it is software, build software.
- Q Why Next.js here and Astro on the marketing site?
- Different jobs. Astro builds pages ahead of time and ships almost no JavaScript, which is exactly right when everyone sees the same thing. An app has to decide what to show you after it knows who you are, so it needs a server at request time. Plenty of projects want both, and there is no rule against running a static marketing site in front of an app on a subdomain.
- Q Why Supabase rather than rolling your own Postgres?
- Because it is Postgres, plus the parts you would otherwise spend a week wiring: auth, row level security, storage, and an API over your tables. Nothing about it is proprietary at the data layer, so the database dumps and restores anywhere, including a box you run yourself if you outgrow it or stop liking them.
- Q How is the data backed up?
- The database dumps nightly to storage on a different provider, because a backup living inside the thing it is backing up is not a backup. Worth being precise though: that covers the database. Files people upload are a separate job, and if you are building this, decide where those go before you have any.
- Q Does it scale?
- Further than most of these ever need, and scale is rarely what kills them. Postgres and Vercel will carry you a long way. What actually bites first is a data model chosen carelessly in week one, which is why the boring part at the start is the part worth slowing down for.
- Q Can it start small?
- It should. The version worth building first is the smallest one that does the single thing people are currently doing by hand. Everything on this page is free or nearly free at low volume, so the cost of finding out whether the idea works is measured in build time rather than infrastructure.