From idea to launched app
Free · 15 minutes · 7 interactive parts · Updated 3 November 2026
Building an app with AI goes in seven steps: plan it on one page, set up the project with save points, add data and sign-in with rules from the start, build one feature at a time, add payments the safe way, go live on your own domain, then watch it through the first month. Each step below has an interactive part to try.
Part 1
How do I plan an app before building it with AI?
Write the plan on one page before the first prompt: the pages people visit, the data tables and who may see each one, the outside services you need, and what costs money per use. Ask your AI to draft it, then correct it. A one-page plan keeps every later prompt consistent, and shows the risky parts before they're built.
Pages
- Home
- Pick a time
- My bookings
- Admin calendar
Tables and who may see them
- bookingsOwner and admin
- servicesAnyone reads, admin edits
- profilesOwner only
Outside services
- Sign-in
- Email reminders
- Stripe deposits
Costs per use
- Email per message
- Stripe per payment
- Keep the first version to three features. Everything else goes on a 'later' list.
- Mark every table with who can read and change it. That becomes your database rules.
Part 2
How should I set up a vibe coding project?
Before building features, connect the project to GitHub, make sure .env files are ignored by git, add a rules file for your AI, and make a first commit. Then commit every time something works. These save points let you undo any AI change in seconds, and keep your secret keys out of the code you share.
Your code lives somewhere safe outside the tool, with full history. App builders usually offer this in settings.
- Most app builders can sync to GitHub from their settings. Turn it on on day one.
- A rules file tells your AI your safety rules once, so you don't repeat them in every prompt.
Part 3
How do I add a database and sign-in safely?
Add sign-in first, then create each table with its access rules in the same step. With Supabase that means turning on Row Level Security and adding policies that limit each row to its owner. Rules added later get forgotten, and a table without them can often be read by anyone who has your app's public key.
| Order | Owner | Total | Maya sees it? |
|---|---|---|---|
| #1042 | Maya | £120 | Yes, hers |
| #1043 | Tom | £80 | Yes: leaked |
| #1044 | Ana | £215 | Yes: leaked |
| #1045 | Maya | £42 | Yes, hers |
- Test it: sign in as a second account and try to read the first account's data.
- Being signed in proves who someone is. The rules decide what they may see.
Part 4
In what order should I build features with AI?
Build in thin slices, where each one works end to end before the next starts: sign-in, then the one thing your app does, then saving it, then payments, then extras. Ask for one slice per prompt, test it, and commit. Asking for everything at once produces code that half-works everywhere, and you can't tell which part broke.
Tap the slices in the order you'd build them.
- 1?
- 2?
- 3?
- 4?
- 5?
- If a slice takes more than a few prompts, it's too big. Split it again.
- Commit after every working slice, so a bad next step is one click to undo.
Part 5
How do I add payments to an AI-built app safely?
Use a hosted checkout such as Stripe Checkout, with the price set on your server, never sent from the browser. Give people paid access only when a Stripe webhook arrives and its signature checks out, and make the webhook safe to receive twice. The success page alone proves nothing: anyone can open it without paying.
Browser → Your server: “I want Pro.” No price is sent: the browser can't be trusted with it.
If you skip it: If the browser sends the price, anyone can edit it to $1. See it happen
- Test with Stripe's test cards and test mode before switching to live keys.
- Live mode has its own keys, prices and webhook secret. Set them all up again.
Part 6
How do I put my app live on my own domain?
Connect your domain to your hosting with the DNS records it gives you, then set your production environment variables and redeploy. Update the site address in your sign-in settings so emails link to the real domain, and set up email sending with SPF, DKIM and DMARC records so messages don't land in spam. Then test sign-up as a new user.
Add the DNS records your host shows you. Changes can take minutes to hours to spread.
Check your domain
- Variables starting with NEXT_PUBLIC_ or VITE_ are fixed at build time: change them, then redeploy.
- Sign up with a brand-new email address on the live site. It's the test that catches the most.
Part 7
What should I watch after launching my app?
For the first month, watch four things: errors (with alerts, so you hear before users write in), bills on every usage-based service, sign-ups for bot patterns, and backups (restore one to prove it works). Most launch-month disasters, like surprise bills, lost data and silent outages, give warning signs days before they hurt.
Day 1: watch
Errors and sign-ups
Watch error alerts as real people arrive. Sign up yourself again, on a phone.
The error nobody saw- Put a spending cap and a billing alert on every paid service before launch day.
- Keep a short log of what you changed and when. It turns a mystery outage into a quick rollback.
Questions
- How long does it take to build an app with AI?
- A simple working version can take a weekend. Making it safe for real users, with database rules, payments, a domain and email, usually takes a few more days of checking.
- Can I build a whole app with Lovable or Bolt?
- Yes, app builders can produce complete apps with sign-in, a database and hosting. You still need to check the security settings, payments and costs yourself before launch.
- Do I need to know how to code to launch an app?
- No, but you need to know what to check. Reading a little code, such as where it runs, what a query asks for and what an error means, makes the checking much easier.
Now see how apps break.
Walk a real incident in four minutes: a customer changes one number in the address bar and sees someone else's invoice. Free, no account needed.