Before You Build: A Practical Guide for Founders

“We need an app” may be the beginning of a useful conversation. It is a poor place to end the diagnosis. A founder considering a portal, product or internal system has several decisions to make before selecting a development partner: which problem is worth solving, what evidence would change the plan, what the business can operate, and what a useful first release must actually accomplish.

This open editorial review edition is designed for a working discussion, not as a complete specification. Bring one real proposal and keep a record of observations, assumptions and decisions as you read.

1. Name the job and the break in the journey

Describe a particular person trying to do a particular task. Then locate where the journey breaks and what follows. “Customers need a portal” proposes a channel. “Repeat buyers call because they cannot see a reliable delivery date after ordering” gives a situation to investigate. Ask how often it occurs, who absorbs the work, and whether the consequence is delay, lost revenue, risk or inconvenience.

Speak to the people doing the work and examine recent cases. A leader’s account, a sales request and a customer complaint can all be informative, but they are different kinds of evidence. Look beyond the screen: a missing decision owner or inconsistent data update may be the source of what looks like a product problem.

2. Choose the uncertainty that matters most

A test should be tied to a decision. List the assumptions on which the proposal rests: customers need the outcome; the team can supply accurate information; a new interface will reduce effort; people will use it. Ask which failed assumption would most change the investment. That is usually the best place to start.

Make the test smaller than the commitment it informs. A manual service, a prototype or a change to an existing workflow may be enough to observe a critical part of the journey. Decide in advance what you will measure, whose behaviour you will observe and what result would cause you to reconsider. A small convenience sample can reveal a problem but rarely establish market-wide demand.

3. Compare responses, not just suppliers

A better process, a configured existing tool and a custom build are all possible responses. Compare them against the actual job, not a generic preference for or against software. Consider speed, control, integration, security, accessibility, flexibility and who will maintain the outcome. Doing nothing for now can also be a conscious choice if the cost of the problem is low and evidence is weak.

A development estimate is only comparable when its boundaries are visible. Check the complete user journey, data preparation, integrations, exception handling, testing, training, support and changes after launch. Ask what the provider expects the client to supply. The lowest initial quote may leave the most important operating work outside scope; the highest quote may include work the business does not yet need.

4. Sequence the dependencies

Teams often call every desirable feature a priority. A more useful question is what must be true before each action can pay off. A campaign depends on a plausible customer and offer. A dashboard depends on definitions and update ownership. An ordering portal depends on stock and delivery data customers can trust. Put those dependencies on the table before choosing dates.

Sequence does not require perfect certainty. It means resolving or explicitly accepting the uncertainties that could make later work wasteful. Name the person who owns each decision and the evidence needed to move forward.

5. Release a complete useful task

The first release can be narrow, but it should let a defined user complete something worthwhile. A booking tool that accepts a request but offers no confirmation or route to reschedule leaves the journey unfinished. Include predictable exceptions, ownership and a way to learn what happened after launch. Remove optional features without removing the core outcome.

Before approval, write down: who the first user is; the task they can finish; which exceptions the team can handle; who operates the service; what adoption or failure signal will be reviewed; and when the next investment decision occurs. A launch date is a constraint. It is not evidence that the service is ready.

A worked decision

Fictional teaching example. A distributor wants an ordering app after repeated customer calls. Investigation shows two possible explanations: buyers cannot place repeat orders easily, or they do not trust stock and delivery information. The team records recent call reasons and tests clearer status updates while checking the accuracy and ownership of the underlying data. If ordering friction persists after information improves, a focused interface test may be justified. If the calls fall because the information is fixed, a full app may be premature. Either outcome is useful because it changes the next commitment.

Take this into a working session

• Write a one-sentence problem statement grounded in a recent case.
• List the strongest observation and the assumption most likely to overturn the proposal.
• Compare at least two credible responses and the operating work each creates.
• Choose a small test, a decision owner and a review date.

Use the decision worksheet to record these answers, or follow the six short lessons with your team. The guide cannot replace specialist assessment for regulated, high-risk or technically complex work.

Research grounding: the UK Government Service Manual on discovery emphasizes understanding users, constraints and the problem before committing to a service; its alpha guidance recommends testing risky assumptions with prototypes. The examples and decision sequence here are Parikh Advisory’s editorial synthesis, not claims of measured client results.