Studio notes
Before you build it, question it
The most expensive words in software are 'I am sure people will want this'. Every year, good money is spent building products that solve problems nobody has, for users who do not exist, in ways nobody asked for. A few honest questions before the build can save months. Here are the five we ask every founder, including ourselves.
Why question an idea before building it?
Every idea rests on assumptions: people have this problem, they care enough to change, they will pay this much, they will use it this way. When those assumptions are wrong, no amount of good code saves the product.
Questioning is not negativity. It is the cheapest form of risk management there is. A conversation costs a cup of tea. A failed build costs months.
Question 1: what is the real problem?
Separate the problem from your solution. 'We need an app' is a solution. 'Customers cannot see their order status and keep calling the office' is a problem, and it might be solved by an SMS update, a simple portal or an app. Lead with the problem and the right solution often turns out smaller and cheaper.
Keep asking 'why' until you hit something painful. Why do they call? Because they are not sure the order is coming. Why does that matter? Because they have customers waiting. Now you understand the stakes.
Question 2: who exactly has this problem?
Describe specific people, not categories. 'SMEs in Kenya' is too broad to design for. 'Owners of hardware shops in Nairobi with two to ten staff who sell on credit' is someone you can find, talk to and build for.
If you cannot name five real people who have the problem, you have homework to do before you have a product to build.
Question 3: how do they solve it today?
Everyone with a problem is already doing something about it: a notebook, a spreadsheet, a WhatsApp group, a relative, or simply living with it. That current solution is your real competitor.
| If today they... | It suggests... |
|---|---|
| Pay for a workaround or tool | Strong demand; they value a solution |
| Spend lots of time on a manual fix | Real pain; time savings will sell |
| Shrug and live with it | Weak demand; the problem may not be painful enough |
| Have never noticed it | You may be solving your own problem, not theirs |
Question 4: what proves they want a better way?
Opinions are cheap. 'That sounds great!' costs nothing to say. Look for commitments instead:
- They give you time: a follow-up meeting, a trial, a pilot.
- They give you information: real data, their actual process.
- They give you reputation: introductions to others with the problem.
- They give you money: a deposit, a pre-order, a paid pilot.
The more people commit, the stronger the evidence.
Question 5: what is the cheapest way to test it?
- Conversations: ten customer interviews about their problem, not your idea.
- Manual service: deliver the solution by hand, using spreadsheets and WhatsApp, for a few customers.
- Landing page: describe the product and measure sign-ups or demo requests.
- Clickable prototype: let people try a mock-up of the core journey.
- Pre-orders or paid pilots: ask for real money.
Pick the cheapest test that would genuinely change your decision. A landing page at CEKAL CREATIVES is KSh 10,000, and clickable prototypes are part of our UI/UX design work.
What if the answers are not what you hoped?
Then questioning did its job. You can narrow the user, reframe the problem, change the solution, or stop before you have spent much. All four are better outcomes than building the wrong thing at full price.
If the answers are strong, move forward with confidence. The next steps are in what to build before you hire developers and from idea to MVP. Want a sparring partner for your assumptions? Start a project inquiry.
Quick answers about validating an idea before building
How do I validate a business idea before building it?
Define the real problem and who has it, learn how they solve it today, look for commitments such as time or deposits rather than opinions, and run the cheapest test that would change your decision.
What are cheap ways to test a product idea?
Customer interviews, delivering the service manually, a landing page that measures sign-ups, a clickable prototype and pre-orders or paid pilots are all low-cost ways to test demand.
Why do products fail after launch?
A common reason is untested assumptions: the problem was not painful enough, the target users were unclear, or the solution did not match how people actually work.
How many customers should I talk to before building?
There is no fixed number, but around ten conversations with people who have the problem usually reveal clear patterns about whether the problem is real and painful.
What counts as strong evidence of demand?
Commitments are stronger than opinions: people agreeing to pilots, sharing real data, introducing others with the same problem, or paying a deposit or pre-order.