Find out if the idea is worth building — before you build it.

Why validation comes before development

A founder with an idea almost always wants to start building. It feels like progress. But development is the most expensive way to test an assumption — every week spent building a feature nobody wanted is a week and a budget you don’t get back. Validation exists to find the wrong assumptions while they’re still cheap to fix: on paper, in a conversation, or in a prototype, rather than in production code.

This doesn’t mean slowing down. A tight validation pass — one to a few weeks — is usually faster than the alternative, which is building for a few months and discovering the same problems the hard way.

Problem validation: is this actually a problem?

The first question isn’t “can we build this?” — it’s “does this problem exist, and is it painful enough that someone will change their behaviour to fix it?” We look for evidence the problem is real today: what people currently do to work around it, what it costs them in time or money, and how often it comes up. An idea solving a mild inconvenience behaves very differently from one solving something people are actively frustrated by.

Customer validation: who feels this, and how badly?

Not every version of “a customer” is the same customer. We narrow the target down to a specific, describable group — by role, situation or behaviour, not just demographics — and test the idea against real people in that group through direct conversations, not surveys alone. The goal is to hear, in their own words, whether the problem matches what they actually experience, and whether your proposed solution is something they’d change their current process for.

Competitor analysis: what already exists, and why hasn’t it solved this?

Existing competitors — direct or indirect, including manual workarounds like spreadsheets — tell you two things: that the market is real enough for something to exist, and where the gap is. We look at what current options get right, what they miss, why customers tolerate the gaps today, and whether your idea closes a gap that matters or just offers a marginally nicer interface.

Business model: how does this become a business, not just a product?

A validated problem doesn’t automatically produce a viable business. We work through who pays, how much, how often, what it costs to acquire and serve a customer, and whether the numbers can plausibly work at a realistic scale — before that model is locked into a product build.

Assumptions and risks: what has to be true for this to work?

Every idea rests on a handful of assumptions — about customer behaviour, willingness to pay, technical feasibility, or regulation. We make those explicit and rank them by how risky and how untested each one is, so validation effort goes toward the assumptions that could actually kill the idea, not the ones that are already obviously true.

Prototype and MVP planning

Where a conversation alone isn’t enough — because people need to see or use something to react honestly — we build a lightweight, low-cost prototype: a clickable design, a narrow working slice, or a manual version of the service run by a person instead of software. This is deliberately not a full build. Its only job is to generate a real reaction from a real customer. What we learn here feeds directly into MVP scope, covered on the MVP Development page.

What you get at the end of validation

A clear, evidence-based answer on whether to proceed, adjust, or stop — plus the material to move straight into MVP planning if the answer is yes: a defined customer, a tested problem statement, a working business model, and a ranked list of the biggest remaining risks.