WRITING

How to build software: what you really need before writing any code

Administrador Building products

Building software starts long before programming. It starts with a well-understood problem, a specific customer and the nerve to build less than you'd like.

Most guides on how to build software start with the programming language.

Wrong order.

Code is the easy part. The hard part is knowing what to build.

Step 1: a problem, not an idea

"I want to make an app that…" isn't a starting point.

"Club treasurers lose their weekends collecting fees" is.

Good software comes from a specific problem that happens to specific people. If you can't describe the problem in one sentence, you're not ready to code yet.

Step 2: someone who has it (and will pay)

Find a real person with that problem.

Talk to them. Watch how they solve it today. Very often the answer is a spreadsheet, a notebook or an exhausted person.

That "how they solve it today" is your competition. It's also your best product manual.

Step 3: the minimum scope

This is where software that ships separates from software that never ends.

Write down everything you'd like it to do. Then keep only what's needed for your first customer to say "this solves my problem".

The rest comes later. Much later.

Software that does one thing well is worth more than software that does ten things halfway.

Step 4: choose how to build it

Now the technical part. You have three paths:

  • Code it yourself, if you can or want to learn.
  • No-code tools, perfect for testing an idea fast.
  • A team or a company that builds it with you.

With AI, building is faster and cheaper than ever. But that makes the earlier steps even more important: nobody can make judgement about what to build any cheaper.

Step 5: put it in real hands

Early. Before it's pretty.

Watch what people do with it. Where they get stuck. What they don't use. What they miss.

Step 6: improve what gets used

The temptation is to add new things. The key is to improve what's already used.

If ten customers use a feature every day, making it a little better changes their lives more than a new feature one person will use.

Order matters

Problem. Customer. Scope. Build. Use. Improve.

It isn't the most exciting order. It's the one that works.

All our products came out that way: from a problem we saw repeating in client work, built first for one and then for many.

P.S. On why judgement is worth more than code: building software is getting cheaper, judgement isn't.

Seguir leyendo