Building a technology startup: what founders should validate before development begins

Most early technology ventures do not fail because the team cannot write software. They fail because the software is built against a problem that was never pinned down, for a customer who was never asked, at a scope that was never costed. Validation is the work of making those three things specific enough that a build can be accepted or refused.

Start with the problem, not the product

A problem worth building for is one a defined person already spends time or money trying to solve. “The market is large” is not that. Write the problem in one sentence that names the person, the situation and the cost of leaving it unsolved. If the sentence still works after you remove the technology, you have a problem. If it only works when the product is in the sentence, you have a feature looking for a reason.

Talk to people who have the problem now, not to people who like the idea. Ten conversations that contradict each other are more useful than a survey that flatters the plan. The point is to find out what they do today, what they have already tried, and what would make them change.

Separate the commercial assumption from the demo

A prototype can prove that a workflow is possible. It cannot prove that anyone will pay, or that the same buyer will pay twice. Before development begins, write down the commercial assumption in words a sceptical operator would accept: who pays, for what outcome, on what cycle, and what has to be true for that payment to be rational.

If the assumption depends on a later round of investment, say so. That is a financing plan, not evidence that the product has a customer. The two should not be blended in the same sentence.

Define the MVP as a boundary

A minimum viable product is a boundary, not a smaller version of the full catalogue. List what the first release will do, and write a second list of what it will not do. The second list is the one that protects the schedule and the budget. Scope that is “the platform, but just the core” is not a boundary. It is an invitation to build the platform.

Feasibility belongs in the same conversation. Some products are expensive because of data, integrations, regulation or operational load, not because of the screens. A founder who has not asked what is hard will approve a scope that cannot be delivered on the resources they have.

Resource planning is part of validation

Engineering time is one cost. Decisions, access to users, content, third-party services and the founder’s own hours are others. A plan that assumes instant answers from the founder will stall, and the stall will be described later as a delivery problem. Agree, before anyone starts, who can accept a milestone and how quickly that person can be reached.

This is also the moment to decide whether the work is a cash engagement, a services-for-equity partnership, or something that should not start yet. Those are commercial choices. They are not a substitute for a validated problem. Hybrid Sweat Equity, as Pixelette describes it, still depends on an agreed scope.

Common early mistakes

• Building to a pitch deck instead of to a customer workflow.
• Treating a letter of intent as evidence of repeatable demand.
• Adding compliance, marketplace and mobile scope to a first release that has no users.
• Hiring a team before the founder can explain what “done” means.
• Using a funding story to avoid a pricing conversation.

None of this guarantees a successful company. It reduces the chance of paying for a product that answers a question nobody is asking. Founders who want a structured view of fit can use the startup partnership assessment and then explore a partnership. That enquiry is a conversation, not a commitment.

Continue

If the questions in this article match a venture you are building, the next step is a conversation, not a commitment.