Start · 8 min read

Start here

What this guide is, who it is for, and the order to work through it.

You have an idea for a web application. You know what it should look like and roughly how it should behave. What you don't have is a developer, a budget, or a background in code.

That gap used to be fatal. It isn't any more — but the reason people fail now is different. It isn't that AI can't write the code. It's that a founder who doesn't understand what the AI is doing ends up with a pile of files they can't change, can't deploy, and can't trust with a customer's email address.

This guide closes that gap. Not by turning you into a software engineer, but by teaching you the specific, small set of things you need to direct one — where the one you're directing happens to be a machine.

⚠️ An honest disclaimer

This guide is written to assist your journey — not to guarantee its destination. Following it carefully can still fail to produce the outcome you want. Software is uncertain, AI tools are powerful but imperfect and occasionally confidently wrong, and plenty of products fail for reasons that have nothing to do with the code.

Our strong advice: don't do this entirely alone. Get a technically experienced person alongside you — a consultant, or a fractional engineer working with you part-time — at two points in particular:

The initial setup. Stack choices, how logins and data access are structured, how things get deployed. These are the decisions that are cheapest to make well and most expensive to reverse.
At checkpoints along the way. Before you take payments, before you store anything sensitive, before you put it in front of real customers. A few hours of review at the right moment is worth more than a month of your own guessing.

When to get tech advice covers how to find that person, what to prepare, and how to tell a good one from a bad one.

Who this is written for

Someone who can look at a web page and say "that heading is too heavy and the spacing is inconsistent", who has poked at HTML and CSS before, and who has never opened a terminal on purpose. If you know what a <div> is but have no idea what npm install does, you are exactly the reader.

Your design literacy is a real advantage, and a bigger one than you think. The single most common failure of AI-built products is that they look and feel like nothing in particular — generic purple gradients, inconsistent spacing, no hierarchy. You already have the eye to catch that. What you're missing is the vocabulary to direct the machine, and the mechanics underneath.

How to use this guide

Work through it in order. Parts 1 to 3 build on each other, and skipping the boring foundations is how people end up three weeks in with a broken project and no way back.

Part 1 — Foundations

The mental model, the tools, the terminal, and version control. Roughly a weekend. Do not skip it.

Part 2 — Building

Your first real build, prompting properly, picking a stack, and going from idea to MVP.

Part 3 — Shipping

Getting online, not getting hacked, not getting a surprise bill, and a weekly working rhythm.

Part 4 — Beyond the MVP

What your shortcuts cost later, handling personal data properly, and when to bring in real help.

Two things appear on nearly every page:

Deep-dive prompts. Copy them into Claude Code or Cursor when you want to go further than this guide does. They're written to make the AI teach you, not just do things for you. All 73 of them are collected in the prompt library.
Exercises. Small, concrete, and each one ends with "you'll know it worked when…". There are 63 in total and your tick boxes are remembered in this browser. The exercise tracker shows them all in one list.

Any word you don't recognise is almost certainly in the glossary.

A realistic six-week plan

Week	What you do	What exists at the end
1	Part 1 in full. Install a tool, learn the terminal, put something on GitHub.	A GitHub account with one small project in it
2	First build and prompting. Rebuild your landing page three times.	A page you designed and directed, live on the internet
3	Choose a stack. Write a spec for your actual product.	A written spec and an empty project that runs
4–5	Build the two or three features that make your product your product.	Something a friendly stranger could use
6	Security pass, deploy properly, put it in front of ten people.	A validated — or usefully invalidated — idea

The three rules that matter most

Never lose work. Commit to GitHub constantly. It is the difference between "that experiment failed" and "I lost four days". Covered in Git and GitHub from zero.
Small steps, checked each time. One feature, look at it in the browser, commit, next. People who ask for ten things at once end up debugging ten things at once.
Understand the shape, not every line. You will never read every line the AI writes, and you don't need to. You do need to know which file does what and roughly how data moves through your app. That's a few hours of learning, and it's what separates directing from hoping.

Exercise 1 Write down what you're actually building

Before you touch a tool. Open a plain text file or a notes app and answer these four questions in no more than two sentences each:

Who is this for, specifically? ("Small landscaping firms in Melbourne", not "businesses".)
What is the single most painful thing they do today that your app replaces?
What is the smallest thing you could put in front of them that would prove they want it?
What does a user have to be able to do on day one — list at most three actions.

You'll know it worked when question 4 has three or fewer items on it. If you have eight, you haven't got an MVP, you've got a roadmap. Keep this file. You'll paste it into the AI many times.

Pressure-test your MVP scope

I'm a non-technical founder about to build the first version of a web app with AI coding tools. Here's my idea:

[paste your four answers]

Act as a sceptical technical co-founder who has shipped several MVPs. Do four things:

1. Tell me which of my three day-one actions is secretly the hardest to build, and why.
2. Point out anything I've assumed is simple that usually isn't (payments, search, file uploads, notifications, anything real-time, anything with permissions).
3. Suggest the smallest possible version that would still genuinely test whether people want this — including whether I could fake part of it manually at first.
4. Ask me the three questions you'd need answered before you could estimate this.

Be direct. Don't flatter the idea.

Get a map before you start

I'm a non-technical founder who understands HTML and CSS but has never used a terminal, Git, or a backend framework.

Explain — in plain English, no more than 600 words — the anatomy of a modern web application: what the frontend is, what the backend is, what a database does, what "deployment" means, and how a request travels from someone clicking a button to data being saved and shown back to them.

Use a concrete example: a user signing up and saving a note. Where does each piece of that live? Avoid analogies about restaurants or libraries; describe the actual components. Finish with a short list of the terms I should now be able to recognise.

When you're ready: How AI coding actually works →