The Build Checklist

1 · The two laws that make building safe

Everything in this method rests on two facts nobody tells beginners. First: you can almost always roll back — version control (GitHub) means nothing you break is permanent. Second: most logic is walled off in its own function, so breaking one thing rarely breaks another. Together they mean the fear is much bigger than the risk.

The working posture follows from that: you are the director, the AI is a very patient senior engineer. When anything confuses you, you never guess — you screenshot the screen and say "assume I have no technical experience; tell me exactly what to click next." That one sentence carries you through every unfamiliar dashboard in the whole journey.

You are allowed to be fearless. The system is more forgiving than the fear is telling you.

2 · Foundation before screens

Excited beginners decorate a house with no foundation — they build the profile page first. The method inverts that: before any screen exists, you brain-dump the whole idea and have the AI produce an architecture and specification document — the feature list split into version-1 and later, the data model in plain language, the security requirements, and everything you forgot to ask for.

That document is saved as SPEC.md and becomes the source of truth the AI reads for every later step. You are not an architect, and you don't need to be: you use the AI to brief you for the AI. Then you trim version 1 ruthlessly — if it has more than about six features, it is not a version 1.

Only then do you scaffold, and you build the core loop first: the one repeated action your platform exists for. Everything else waits.

The most important prompt of the journey is the architecture prompt. It is in the library — start there.

3 · The professional stack, demystified

Three services carry the whole product, all with free tiers. GitHub is memory and the safety net. Vercel is the address on the internet — it watches your GitHub and redeploys on every push. Supabase is the filing cabinet and the doorman: database, sign-in, and file storage in one.

The single most confusing thing for novices is which key goes where. The rules never change: anything named "secret", "private" or "service_role" stays server-side only — never in frontend code, never in GitHub, never pasted into a chat. Public keys carry a public prefix and may ship to the browser. And .gitignore must always exclude your .env.local file.

Security is not a cleanup phase: Row Level Security goes on every table the day it is created, so users can only ever read what they should. Emails are private credentials, never public identifiers — usernames are the public face.

When switching payment keys from test to live, ONLY environment variables change. If code changes, keys were hardcoded — that is the real bug.

4 · The heartbeat: notifications, testing, optimisation

A social product is not a place; it is a heartbeat. People come back when they see movement — an in-app bell, then web push (the VAPID public key goes to the frontend, the private key to server secrets, and nowhere else). Notify only on the three to five events a user genuinely cares about; too many notifications teach people to ignore you.

Then you test like a professional: inventory every page and function, get a phased test plan, run it with the AI, then walk every function by hand on the live site. Users do not file polite bug reports — they leave quietly, forever.

And you optimise because it is the difference between a product and an expensive hobby: cap uploads, serve WebP not JPEG, batch the database writes that don't need to be live, paginate every list. Then ask the open question: what is THIS product wasting?

Stop testing when you are happy, not when you are tired.

5 · Money that flows correctly

First find who actually holds the money in your ecosystem — the users may be the value, not the customer. People also pay for how a platform makes them feel: status, visibility, verification.

Then wire payments in the only safe order: test keys first, always. Payment confirmations come from a signature-verified webhook, never from the user's browser — browsers can lie. Only when the full test checklist passes do the live keys go in, and the first real payment is one you make yourself and refund.

The marketplace unlock is subaccounts and split payments: every vendor's share goes straight to them, your percentage to you, and you never hold anyone else's money — which keeps you out of the regulatory swamp.

Know your numbers cold: "At [N] customers paying [PRICE], I am sustainable." If you can't fill that in, you don't have a business model yet.

6 · Being found, going native

Discoverability now means two audiences: search engines (SEO) and the AI answer engines more people ask instead (AEO). The checklist covers both: Search Console and a sitemap for Google; an llms.txt file, meta tags and schema.org structured data so an AI answering "what's a good way to do X in your city" understands and recommends you. Give the machine a map, not a maze.

Going native is borrowed credibility — a real app in the App Store and Google Play changes every conversation. One React codebase covers web, iOS and Android, tested on your own phone through Expo Go. The discipline that makes it work is parity: after every feature, forever, confirm it exists on all three platforms, because the AI will always drift.

The final sweep is the unglamorous professional layer: backups you know how to restore, error monitoring, analytics on the three numbers that matter (visits, sign-ups, core-loop completion), and rate limits so one bad actor can't flood you.

Rejections from app review are common and normal: read the reason, paste it to your AI, fix, resubmit.