How to build an application for your customers
Building your own customer-facing app is now normal work — start small, break it down, and ship it.
I built a real, customer-facing application, and this is how — step by step. AI does most of the typing now; that is simply the normal way to build, not the headline. So the real work is the judgement: what to build first, how to keep it secure, where to host it, and making it feel simple to use. Below is the actual build, in order.
Right now
Live and serving paying customers. Here is the build, step by step.
The findings
The whole report, open: what it cost, what broke, step by step — and what I’d do differently.
Overview
This is a build log, not a manifesto. I set out to make a real application for real customers and to write down exactly how it went — so that someone with a clear idea and a little nerve could follow the same path.
Yes, an AI assistant wrote most of the code. I say that plainly and then move on, because it is now simply the normal way to build — the interesting part is not that AI typed it, but the decisions that made it worth typing at all.
Start small, with a clear definition
One sentence first
No matter what you build or how, start small and define it clearly. Write the single sentence that says what one customer gets and what they pay for it. If you cannot write that sentence, you are not ready to build — you are ready to think a little longer.
Refuse the second feature
The assistant will happily build you a cathedral. You want a kiosk that takes coins. Name the smallest thing a stranger would actually pay for, build only that, and let everything else wait until the first version is real.
Break the features down
Once the one sentence is clear, break it into the smallest pieces that can each be built and checked on their own: the account, the core action, the payment, the confirmation. Small pieces are easy to describe, easy to test, and easy to fix when one of them is wrong — and one of them will be wrong.
This is also how you stay in control of an assistant that writes fast. If you ask for a whole system at once you get a whole system you do not understand. Ask for one piece, read it, ship it, then ask for the next.
The security that actually matters
Get the few basics right
You do not need a security department; you need to not make the well-known mistakes. Never store passwords you could have avoided. Keep secrets out of the code and in the platform's secret store. Put every real action behind a signed-in session, and check that session on the server, never only in the browser.
Least surprise, least access
Give each part of the system only the access it needs — the database user, the deploy account, the API keys. Most breaches are not clever; they are a key left where it should not have been. Ask the assistant to explain the risk of each piece before you ship it, and make it justify anything it wants to expose.
Hosting on Google Cloud
I host on Google Cloud. The app is a container on Cloud Run, which sleeps when no one is visiting and costs almost nothing while it sleeps, then wakes in a moment when a customer arrives. The database and the file storage are managed services next to it, so there are no servers for me to nurse.
One gated door to production
Deploys are a single command, and there is a staging copy that mirrors production so I can look at a change on a real URL before customers do. The rule I keep: nothing reaches production that has not been seen working somewhere safe first.
Feature one — passwordless login
A magic link, no password
The first feature was the account, and I chose passwordless: you type your email, you get a link, you click it, you are in. No password to forget, to reuse, or to leak — which quietly removes a whole category of the security worries above.
Mailjet sends the mail
The links go out through Mailjet, a transactional email service, so they arrive reliably instead of landing in spam. The link carries a short-lived signed token; clicking it mints a session; the session is what every other feature checks. Simple, boring, and hard to get wrong once it is right.
A simple UI — Figma first
Last, the part people actually see. I do not ask the assistant to "make it look nice" — that is how you get something generic. I draft the screens in Figma first, decide the type, the spacing, the one accent colour, and then hand that over as the thing to match.
With a picture to build against, the interface comes out calm and consistent instead of improvised. It is the same lesson as everywhere else in the build: the AI is fast and willing, but the judgement — what small, what secure, what simple — is still the work, and it is still yours.