The gap between "I have decided" and "someone is using it" is where most first businesses die. Not because building is impossible, but because people imagine the first version has to be good.
It does not. The first version has one job: to be real enough that someone can react to it. Everything in this chapter is about getting there fast and then improving in public.
Write the one page brief
Before anything gets built, write down what you are building. One page. Not a specification document, not a deck. A page.
It needs four things:
Who it is for. The specific person from chapter one, not the category. "An independent dental practice with three to ten locations", not "small businesses".
What problem it removes. In their words, not yours. If they say "we keep losing claims", write "we keep losing claims". Do not translate it into "claim lifecycle visibility".
What happens instead. The new reality after they use it. Be concrete about the outcome, not the feature. "Denied claims get re-filed the same day" is an outcome. "Automated claim workflow engine" is a feature that has been dressed up.
What you believe that others do not. One sentence. This is the thing that makes your version different from the obvious version.
The reason this fits on one page is that anything longer is you avoiding a decision. If you find yourself writing "and also", stop and ask whether the "also" is really part of the first version. Usually it is chapter three of your ambition sneaking into week one of your work.
Keep the page. You will refer back to it more than you expect, mostly to notice how far you have drifted.
Cut it down to a first version
Now cut. This is the skill that separates people who launch from people who keep almost launching.
The test for every feature is the same: if this were missing, would the first version still solve the problem? If yes, it is out. Not forever. Out of version one.
Some things that feel essential and almost never are:
- Accounts and logins, if a person could get value on their first visit without one.
- Settings and preferences. Pick a sensible default and move on.
- An admin area. You can look at the data yourself for a while.
- Multiple pricing tiers. One price, or a conversation, is fine at the start.
- Anything described as "for when we scale". You are not there.
Some things that genuinely are essential:
- The one thing your customer came for, working properly.
- A clear explanation of what this is, on the first screen.
- A way to contact you.
- A way to pay, if you are charging.
There is a useful way to frame the cut. Imagine your customer describing your product to a colleague in one sentence. Whatever survives in that sentence is version one. Everything else is later.
Being small here is not modesty, it is speed. A smaller first version reaches a real person sooner, and a real person will tell you things that no amount of planning will.
What the first build actually gives you
Here is the honest picture of what happens when a first version gets built for you, so you know what to expect and what still needs you.
You get a working site, quickly. Real pages, real navigation, something you can click through and send to someone. Depending on the idea, that can be a landing page that explains the offer, or an actual working tool.
It will look better than you expect and be less finished than you want. The layout, the typography, the general shape will be fine. The details will be generic, the copy will be approximately right rather than exactly right, and there will be a few things that are simply not what you meant. That is normal. It is a first draft, and first drafts are for reacting to.
Your job shifts from describing to judging. This is the important change and it catches people out. Before, your job was to explain the idea. Now it is to look at something concrete and say what is wrong with it. That is a different and much easier job, and it is why getting to a first version fast is worth so much.
What it does not do is read your mind. If a detail matters, say so. "Make the pricing page show three plans with the middle one highlighted" gets you what you want. "Make the pricing nicer" gets you a coin flip.
Show it to people before you polish it
The instinct is to fix everything first. Resist it, because you do not yet know which things are worth fixing.
Take the rough version to five people who have the problem. Not friends who will be nice, and not a public launch. Five people who might actually buy.
Watch, do not present. Give them a task and be quiet. "Here is the site, imagine you needed to file a claim, see what you'd do." Then say nothing, even when it hurts, because the silence is where you learn.
What you are looking for:
- Where they pause. Confusion is silent. A three second hesitation on a button means the label is wrong.
- What they say out loud. The words they use are better than the words you wrote. Steal them.
- What they ignore. The feature you were most proud of, scrolled past without a glance, is data.
- Where they stop. The point where someone gives up is the only bug that matters this week.
And one question at the end, asked plainly: would you use this? If they say yes, follow up with "when?" and watch what happens to their face. Vague enthusiasm is polite. A date is real.
Fix what stopped people. Ignore everything else for now, including your own taste. You will have plenty of time to make it beautiful once you know it is wanted.
Let people pay you
Take money earlier than feels comfortable. Not because you need the revenue, but because paying is the only feedback that cannot be faked to spare your feelings.
A few things that make this easier:
Charge for the outcome, not the effort. Nobody cares how hard it was to build. They care what it saves them. If your thing saves a clinic four hours a week, price it against four hours of someone's time, not against your hosting bill.
Pick one price and see what happens. You will be wrong. That is fine, because being wrong at one price teaches you more than being undecided across three. Most first-timers price too low, then feel resentful, then quietly stop selling.
Do not build a billing system. Use a payment provider, connect your own account, and let it handle cards, receipts, and refunds. This is a solved problem and it is not where your originality belongs.
Say the price out loud, on the page. Hiding pricing behind "contact us" is a choice that makes sense for large deals and almost nothing else. Early on it just filters out the people who would have bought.
The first payment changes the project. Before it, you have an idea people were nice about. After it, you have a business with one customer, and that is a completely different thing to wake up to.
Put it live
Live means a real address that someone can open on their phone without you being in the room.
That is a lower bar than "launched". There is no announcement here, no Product Hunt, no press. Just a link that works, that you can put in a message to one person.
What "live" needs:
- An address that loads for anyone, not just you.
- A first screen that says what this is within a few seconds of arriving.
- The one thing it does, actually working.
- A way to reach you when something breaks, because something will.
What "live" does not need: a launch date, a logo you love, a privacy policy written by a lawyer, or anyone else's permission.
The reason to get here fast is psychological as much as practical. An unshipped project is a private worry. A live link is a thing that exists, and people respond to things that exist.
Keep it working
Once something is live, the job changes shape again. You are no longer building toward a launch, you are running a thing that people use. That is a rhythm, not a sprint.
A rhythm that works for most people at this stage:
Fix what is broken, immediately. A broken payment or a page that will not load beats every other priority. Nothing else you could do this week is worth more than the customer who cannot check out.
Change one thing at a time, and watch. If you change five things and the numbers move, you have learned nothing. If you change one thing, you know what did it.
Write down what you tried. Not a formal log. Just a running note of what you changed and what happened. In two months you will not remember, and you will re-run the same failed experiment.
Resist adding. Every new feature is a promise to keep it working forever. The default answer to a feature request from a single customer is "not yet". The answer changes when the fourth person asks for the same thing.
One thing worth being clear about, because the industry is full of overclaiming: a tool that plans for you is not the same as a tool that acts for you. It is genuinely useful to wake up to a considered list of what to do next. It is a different thing entirely for changes to appear on your live site while you sleep, and you should want the second one to require your say-so. Approval is not a limitation here, it is the reason you can trust the thing at all.
Next up: Chapter III is about getting people to show up in the first place.