Part 2 — Building · 18 min read
Choosing a cheap stack
The boring, well-documented, near-free toolkit that AI writes best — with real monthly numbers.
"Stack" just means the set of technologies your app is built from. This choice matters more for you than for an experienced developer, for one specific reason: AI writes popular, well-documented technology far better than clever, niche technology.
Your selection criteria aren't "what's best". They're: what has the most tutorials, the most Stack Overflow answers, the most examples in training data, and a generous free tier. Boring is a feature.
The recommendation
| Layer | Use | Why |
|---|---|---|
| Framework | Next.js with TypeScript | The most written-about web framework there is. Frontend and backend in one project, which halves the number of things you must understand. |
| Styling | Tailwind CSS | Styling written as classes in the markup. AI is exceptionally good at it, and with your CSS knowledge you'll read it fluently within a day. |
| Components | shadcn/ui | Accessible, well-made components copied into your project rather than installed — so you can restyle them freely. Solves the "everything looks like a default template" problem. |
| Database + auth | Supabase | A real Postgres database, user accounts, and file storage, with a usable dashboard. Free tier is genuinely enough to validate. |
| Hosting | Vercel | Connect your GitHub repo; every push deploys automatically. Made by the people who make Next.js. |
| Resend | Sending email reliably is genuinely hard. Resend's free tier covers early usage and the API is simple. | |
| Payments | Stripe | Only when you actually need it. No monthly fee — it takes a percentage. Stripe Checkout is a hosted page you redirect to, which keeps card data entirely away from your app. |
What it actually costs
Roughly, for a pre-launch product with a handful of beta users:
| Thing | Free tier | When you start paying | Then roughly |
|---|---|---|---|
| Vercel | Hobby: generous | As soon as it's commercial — Hobby is non-commercial use only | ~US$20/mo (≈A$31) |
| Supabase | Free project, pauses after inactivity | When you need it always-on, backups, or more storage | ~US$25/mo (≈A$39) |
| Resend | A few thousand emails/month | Higher volume | ~US$20/mo (≈A$31) |
| Domain | — | Immediately | ~A$20–25/year for a .com; .com.au similar |
| Stripe | No monthly fee | Per transaction | ~1.75% + A$0.30 on Australian cards; ~3.5% + A$0.30 international |
| AI tooling | Limited | Basically immediately | ~US$20–40/mo (≈A$31–62) |
If not Vercel — and if not Supabase
These two do completely different jobs, and it's worth being clear before comparing anything: Vercel hosts and runs your app; Supabase stores your data and handles logins. You need one of each. Swapping one doesn't replace the other.
Alternatives to Vercel (hosting)
| Option | Free tier | Pick it when | The catch |
|---|---|---|---|
| Vercel | Generous, but non-commercial only | You're on Next.js and want zero configuration. Still the default recommendation. | You must move to a paid plan the day you charge anyone. |
| Netlify | Generous, commercial use allowed | You want the same push-to-deploy experience without the commercial restriction. | Next.js support is very good but a step behind Vercel's, since Vercel makes Next.js. |
| Cloudflare Pages / Workers | Very generous, commercial use allowed | Cost matters most, or you're already buying your domain there. | Next.js runs through an adapter, which occasionally means a feature needs a workaround. |
| Render | Yes, but free services sleep when idle | You want a normal always-running server rather than serverless, with predictable pricing. | The free tier's cold starts are too slow to demo on. |
| Railway | Small trial credit | You need a database, a background worker and an app together in one place. | Usage-based billing — set a cap on day one. |
| Fly.io | Limited | You specifically want your app running in Sydney, close to Australian users. | More concepts to learn. Not a beginner's first host. |
| A plain VPS (DigitalOcean, Hetzner, Vultr) | No | Much later, when scale makes per-request pricing hurt. | You now run a server: updates, security, backups, uptime. Avoid for an MVP. |
Alternatives to Supabase (database and logins)
| Option | What you get | Pick it when | The catch |
|---|---|---|---|
| Supabase | Postgres, auth, file storage, dashboard | You want one service that covers nearly everything. Still the default recommendation. | Row Level Security is off by default — the trap described above. |
| Neon | Postgres only, generous free tier | You want a great database and will bring your own logins (Clerk, Auth0). | Two services to wire up instead of one. |
| Firebase | Google's database, auth and hosting | Your app is heavily real-time — live chat, collaborative editing. | Not a normal relational database. Harder to move away from, and harder to reason about as data grows. |
| Convex | Database plus backend logic together | You want the smallest possible amount of glue code. | Smaller community means fewer examples in AI training data — which matters more for you than for an engineer. |
| Clerk / Auth0 (logins only) | Sign-up, login, password resets, social logins | Auth is your painful part and you want it solved properly. | Another subscription, and free tiers are capped by user count. |
Things that will tempt you, and shouldn't
| Temptation | Reality |
|---|---|
| "I'll need a mobile app" | Build a responsive website first. It works on every phone immediately, with no app stores and no review process. Convert later if people actually want it. |
| "I need to run my own server on AWS" | You'd spend your first three weeks on infrastructure instead of product. Managed hosting until it genuinely hurts. |
| "I should use a newer, better framework" | Fewer examples in training data means worse AI output and fewer answers when you're stuck. Popularity is a feature for you. |
| "I need microservices / Kubernetes / a queue" | Those solve problems you'll have at thousands of users. You have zero. |
| "I'll build my own login system" | Never. Auth is where security bugs live. Use Supabase, Clerk or Auth0 and move on. |
| "I'll add AI features to my product" | Fine, later. Watch the cost per user — AI features can quietly cost more per user than you charge. |
Databases, in five minutes
A database is a set of tables. Each table is like a spreadsheet with strictly enforced columns. The concepts worth knowing by name:
- Table — one kind of thing.
users,bookings,dogs. - Row — one of them. One booking.
- Column — one fact about it, with a fixed type.
start_timeis always a timestamp. - Primary key — the unique ID of a row.
- Foreign key — a pointer to a row in another table. A booking's
user_idpoints at a user. This is how tables relate. - Migration — a recorded change to the shape of your database. Always do these as migrations, never by clicking around in a dashboard, or your local and live databases will drift apart and you'll have a very bad afternoon.
- Row Level Security (RLS) — database-enforced rules about who can read and write which rows. Read the warning below.
Words you'll meet, briefly
| API | A way for programs to talk to each other. Your frontend calls your backend's API; your backend calls Stripe's. |
| API route / endpoint | One specific URL on your backend that does one thing. |
| Server / client component | In Next.js: code that runs on the server (can touch the database, secrets are safe) versus in the browser (can be interactive, but everything in it is public). |
| Environment variable | A setting that lives outside your code — usually a secret. Different values locally vs live. |
| Build | Turning your source code into the optimised bundle that actually gets served. |
| Deploy | Putting that build on the internet. |
I'm a non-technical founder with design experience. I'm building [describe your app in 3-4 sentences, including what users do and what data it stores].
Recommend a stack, but justify it against MY constraints specifically:
- I'll be building with AI coding tools, so I need technologies that are extremely well represented in training data
- Budget under A$80/month until I have paying users
- I'm solo, so I can't afford to run infrastructure
- I need to be able to hand this to a contract developer later without them wincing
Give me:
1. Your recommendation, layer by layer, with one sentence of justification each
2. Where my particular app has a requirement that changes the usual answer
3. What I'd be giving up versus a more sophisticated choice
4. A realistic monthly cost at 0, 100 and 1,000 users, in Australian dollars — note which services bill in USD and assume a rate of about 1 USD = A$1.55
5. The one decision here that would be most painful to reverse later, and how to stay flexible on it
Help me design the database for [describe your app]. Don't write any code yet.
Interview me about what the app needs to store, then propose a schema. For each table, show me:
- What real-world thing it represents
- Its columns, their types, and which are required
- How it connects to other tables
- Who should be allowed to read and write each row
Then:
1. Draw the relationships as a simple text diagram
2. Explain it back to me in plain English, as if describing a filing system
3. Flag the three decisions here that would be most painful to change once I have real data
4. Tell me what I've probably forgotten — the fields people always wish they'd added from the start
5. Write the row level security policies alongside the tables, and explain what each one allows
Be specific about anything involving dates, times, money or timezones — I gather those cause the most pain.
I'm a non-technical founder building [describe your app] for the Australian market. It's a [Next.js / other] app using [Supabase / other] for data.
Compare hosting options for me — Vercel, Netlify, Cloudflare, Render, Railway, Fly.io — against my actual constraints:
- I will be charging users within a few months, so non-commercial free tiers are a trap
- My users are almost all in Australia, so latency to Sydney matters
- Some customers may ask where their data is physically stored
- I'm solo and non-technical, so I can't run servers
- I want predictable costs, not usage-based surprises
For each option tell me: what the free tier really allows, what I'd pay in AUD once commercial, which regions it can run in, how hard it would be to move away later, and how well it handles my specific framework.
Then recommend one, say what I'd be giving up, and tell me the one thing that would make you change your recommendation.
I'm about to commit to [stack]. Before I do, teach me enough to be dangerous.
For each part of the stack, explain in plain English:
1. What it does, and what would break if I removed it
2. Which files in my project belong to it
3. The three concepts I need to understand to not be lost
4. The most common beginner mistake, and how to spot it
5. Where the real documentation lives, and which section to actually read
Then give me a single mental model of how a request flows through the whole stack: user clicks a button → what happens, in order, until they see a result. Name the specific files in my project at each stage.
Use the stack prompt above with your real idea. Then go to the pricing pages of each service and check the numbers yourself. Write down your expected monthly cost at launch and at 500 users.
You'll know it worked when you have a number you'd be willing to say out loud to an investor, and you know which service becomes the most expensive first as you grow.
Before writing any code, use the database prompt above. Then draw the tables and their connections by hand — boxes and arrows, on actual paper. Explain it out loud to someone non-technical.
You'll know it worked when you can explain what happens to the data when a user does the main thing your app is for, without looking at your notes. If you get stuck explaining it, the schema is wrong, and finding that out now is worth an entire weekend later.
Create a Supabase project and a test table with some fake data. Deliberately leave RLS off. Then ask your AI tool: "Show me how someone could read this table from outside my app using only the public anon key." Run it and watch your data come out.
You'll know it worked when you've seen your own supposedly-private data appear in a terminal. Then enable RLS, add a policy, and try again — it should fail. Nothing will make you check this again as reliably as having seen it once.