Building it: the least you can learn from

The short version. The purpose of a first version is to learn whether the idea works — nothing else. Every hour spent on parts that don't serve that question is an hour spent decorating a hypothesis. Decide what you need to learn, then build the absolute least that can teach it — which, more often than people like, means not building software at all yet.

1. Write down the question first

Before anything gets made, finish this sentence: "This version exists to find out whether ___." Whether plumbers will photograph their paperwork. Whether parents will pay a deposit before the club exists. Whether the report is good enough that someone asks for a second one. If you cannot name the question, you are not building a first version — you are just building.

2. The ladder of fakes — climb it before you code

Each rung below answers real questions at a fraction of the cost of the rung above it:

• A landing page that describes the product and takes sign-ups — tests whether the promise lands, before anything exists.
• Doing it by hand (the "concierge" version): deliver the service manually to a handful of customers. You learn what they actually need, and they pay you to teach you.
• The hidden-human version: the customer sees a product; behind the curtain, it's you doing the work the software would do. Tests the experience without the engineering.
• No-code and spreadsheet tools: form builders, automation glue, a database with a nice front. Embarrassingly effective for v1, and disposable by design.
• Real code — the top rung, earned only when the rungs below have run out of things to teach you.

3. Scope like a coward

One kind of user. One problem. One path through, working end to end. Everything else — settings, edge cases, the second user type, the admin screen — goes on a list marked later, and most of it will die there quietly once real users show you what actually matters. A narrow thing that works teaches more than a broad thing that nearly does.

4. Buy the boring parts

Payments, logins, email, hosting, scheduling — solved problems, rentable for pennies, and invisible to your idea's actual test. Building any of them yourself at this stage is procrastination wearing a hard hat. Your effort belongs in the one part that is genuinely yours.

5. Beware polish — it is fear, dressed up

"It's not ready to show people yet" usually means "I am not ready for people's verdict". The scrappy version shown this month beats the polished version shown next quarter, because only one of them produces learning. If showing it doesn't make you slightly uncomfortable, you waited too long.

6. Two cautions worth carrying from the later guides

If any part of the idea might be patentable, showing it publicly can cost you those rights — read the patents guide before the launch post, and keep the clever part behind the curtain. And if a freelancer builds any of this for you, get the copyright assigned in writing before they start — the copyright guide explains why the default answer is that they own it.

The whole thing, on one line

Name the question → climb the ladder of fakes before you code → one user, one problem, one path → buy the boring parts → ship scrappy and let real users write the rest of the spec.