Before You Spend €20,000 Building It, Read This

€20,000 is an awkward amount of startup money. It is large enough to damage your runway and small enough to feel like a reasonable first build. A software agency can produce a convincing proposal for it. A developer can explain how much will fit inside it. A founder can tell themselves that spending it will finally create momentum.

But a detailed quote does not make the underlying decision sound. Before you ask who should build the product, ask whether the product has earned the right to be built.

A build is not evidence

Founders often treat software as the thing that will reveal whether an idea works. Sometimes it does. More often, the software arrives after the important assumptions could have been tested much more cheaply.

If your idea depends on people changing a habit, trusting an unknown company, paying a new category of expense or inviting colleagues into a workflow, code does not answer the first question. A conversation, a manual service, a clickable prototype or a plain landing page might. Those methods are less exciting because they do not look like a company yet. That is precisely why they are useful: they test the decision without forcing you to defend a large investment.

The dangerous sentence is: “Once people see the product, they will understand.” It may be true, but it is usually used to skip the difficult work of explaining the value clearly. If the value cannot survive a simple explanation, a polished interface rarely rescues it.

Write down what must be true

Before approving a budget, list the assumptions that would make the product worth building. Keep them specific.

You may need to believe that a particular buyer has the problem often enough to pay for relief. You may assume that existing tools are genuinely inadequate rather than merely unpopular with you. You may assume that data is available, an integration is permitted, users will complete onboarding, or a team will change its process.

Then separate those assumptions into two groups: assumptions that require software to test and assumptions that do not. Most early lists contain surprisingly little in the first group.

Do not write “customers want this.” Write what customers do now, what that costs them and what commitment would count as evidence. A compliment is not a commitment. A survey response is weak evidence. A paid pilot, a signed letter of intent with real conditions, access to required data or repeated use of a manual version is stronger.

Price the uncertainty, not the feature list

A proposal usually prices screens, integrations, roles and technical tasks. It rarely prices uncertainty. Yet uncertainty is what makes an early product expensive.

A login screen is predictable. Whether anyone returns after logging in is not. An integration can be estimated. Whether the partner grants production access may not be. A dashboard can be designed. Whether its numbers change a decision is the real question.

Take the proposed scope and mark every item that depends on an untested belief. Those items should not automatically be built. They should trigger a cheaper test or a smaller first version.

This also changes how you compare quotes. The cheapest quote is not automatically efficient, and the largest quote is not automatically thorough. A good proposal reduces risk in stages. A weak proposal accepts your requested feature list and starts counting days.

Find the smallest useful transaction

An MVP is not a reduced version of your eventual product. It is the smallest complete exchange of value between you and a customer.

For a marketplace, that may mean manually matching one buyer and one seller. For a reporting product, it may mean producing the report by hand from a spreadsheet. For an AI product, it may mean delivering an outcome with human review behind the scenes. For a workflow tool, it may mean handling one painful step instead of replacing the entire process.

The first version can be operationally ugly. It cannot be unclear about who receives value and why. Founders often automate too early because manual work feels unscalable. At this stage, manual work is research. It shows where exceptions appear, what customers ask for and which steps deserve automation.

Protect an escape route

Every early build should have points where you can stop without pretending the full budget must be spent. Ask for phases tied to decisions, not just technical milestones.

A useful first phase might end with a validated prototype, a technical spike around the riskiest integration or a working slice that one customer can use. At that point, you should be able to continue, change direction or stop. “Backend complete” is not a useful decision point if no customer outcome exists.

Avoid paying for a broad foundation before the narrow use case works. Flexible permissions, generalized workflows, multi-language support, native apps, elaborate analytics and infrastructure for hypothetical scale can all sound responsible. They also make changing your mind slower.

The questions to answer before signing

Before you approve the work, answer these without sales language:

• Who has the problem, and what do they do about it today?
• What evidence shows the problem is urgent enough to change behaviour?
• Which assumption is most likely to make the product fail?
• What can test that assumption without custom software?
• What is the smallest end-to-end outcome a customer can use?
• What can be removed without weakening that outcome?
• At what point can you stop the project with useful learning?
• Who owns the code, accounts, infrastructure and documentation?
• What ongoing costs begin when the build ends?

If the answers are vague, the estimate is not your biggest problem.

Spend when the decision becomes boring

You do not need certainty. Startups never get it. You need enough evidence that the next investment is a sensible way to learn more.

The best time to spend €20,000 is not when enthusiasm is highest. It is when the customer, problem and smallest useful outcome are clear enough that the build feels almost obvious. The technical work can still be difficult. The business reason for doing it should not be.

Before you hire the developer or accept the software agency proposal, get someone experienced to challenge the assumptions, scope and sequence. One direct conversation is cheaper than discovering halfway through the build that the product should have started as a landing page and a spreadsheet.

Ask Ronald before you spend