I have an idea for a system. Now what? The road from idea to software

Why starting with the screen is almost always a mistake

When someone describes an idea, they usually describe screens: 'there's a registration form, a dashboard, a report.' Screens are the visible result of a system, not its foundation. Starting with them is like choosing the cladding before knowing how many floors the building will have.

The foundation is the problem: who suffers from it, how often, how much it costs today to live with it, and what the person currently does to work around it. Until those four answers exist in writing, any estimate of timeline and price is fiction.

• Describe the problem in one sentence, without mentioning technology.
• Identify who foots the bill for the problem — it isn't always the person who uses the system.
• Measure the current cost: lost hours, errors, rework, missed sales.
• List today's improvised workaround (a spreadsheet, WhatsApp, a notebook). It's your real competitor.

How to validate an idea before investing

Validating isn't asking whether people liked it. Everyone likes other people's ideas in a polite conversation. Validating means looking for evidence of behavior: is someone already spending money, time, or attention trying to solve this problem today?

There are cheap ways to gather that evidence before writing a line of code: interviews with questions about the past (not the future), a page that explains the proposal and measures real interest, a clickable prototype, or even manually running the service for the first ten customers.

• Ask 'how did you solve this last time?' instead of 'would you use an app like this?'.
• Prefer signals that carry a cost: scheduling a call, leaving a contact, paying for a pre-sale.
• Run the service by hand before automating it — that's how you learn the real business rules.
• Write down objections. They become requirements.

What comes first: prototype, architecture, or coding?

The healthy order is: understanding the problem, a low-cost prototype, architecture decisions that are hard to reverse, and finally implementation. Fred Brooks, in his classic reflection on software projects, already warned that adding people to a late project makes it later still — reinforcing that planning early costs less than fixing late.

Not every decision needs to be made at the start. The technique is to separate reversible decisions (button color, chart library) from expensive-to-change decisions (data model, authentication strategy, multi-tenant or not, tax integration). The expensive ones deserve time; the cheap ones deserve speed.

Requirements: the document that avoids 80% of the arguments

A requirement isn't a list of features. It's the description of what the system must guarantee for the business to work: who can do what, what must never happen, which numbers need to reconcile at month's end, how long the user is willing to wait.

Ian Sommerville popularized the distinction between functional requirements (what the system does) and non-functional ones (how well it does it: performance, security, availability). Projects tend to die on the non-functional ones, precisely because no one wrote them down.

• Functional: 'the manager approves an order above $5,000'.
• Non-functional: 'the approval must be logged with author, date, and IP, and the history is immutable'.
• Business rule: 'an approved order cannot be edited, only canceled'.
• Acceptance criteria: how to tell, without debate, that something is done.

An MVP isn't a crippled version of the product

An MVP is the smallest version capable of generating real learning with real users. The word that matters is 'viable': an MVP delivers complete value along a narrow path, rather than delivering half a path across many fronts.

A useful analogy: if the goal is transportation, a working skateboard teaches more than a quarter of a car. The common mistake is confusing an MVP with a poorly built product — the scope is small, but the quality of what exists needs to be real, including security and data handling.

How much it costs and how long it takes

There's no price list for custom software, for the same reason there's no price list for a construction project: cost is a function of scope, integrations, required quality level, and risk. What does exist is an honest way to estimate.

Reliable estimates come from scope sliced into small deliverables, with ranges instead of exact numbers, and revised at every cycle. Whoever promises a fixed number before understanding the business rules is taking on a risk that, sooner or later, shows up in quality.