What I Look at Before I Agree to Build Anything

Most developers start with: what do you want me to build?

I stopped starting there a while ago. It's the wrong question. Not because it's impolite or because I'm trying to be difficult — but because a founder who answers it honestly is only telling me the solution they've already imagined. And the solution they've imagined is usually built on assumptions they haven't tested yet.

The better starting point is the problem. Not the product. The problem.

The questions I actually ask

Before I agree to build anything, I want to understand six things.

Who is the user, specifically? Not "small business owners." Not "gamers." The actual person — their daily reality, the decisions they make, the things they are responsible for, what they're afraid of getting wrong. The more specific, the better. If a founder can't describe their user with that level of precision, the product design will be imprecise too.

What is the user doing today without your product? Every product replaces something — a spreadsheet, a WhatsApp group, a paper notebook, someone's memory. Understanding what people do right now tells you what the real competition is. It also tells you how much friction you're asking someone to absorb in order to switch.

What does success look like in 12 months? Revenue number. User count. A specific operational outcome. I need to know whether we're building toward a product that has 10 highly-committed paying customers or 10,000 trial signups. Those are entirely different products even if the feature list looks the same.

What is the acquisition path? This is the question most founders defer. They want to build first and figure out distribution later. But the acquisition path shapes the product. If you're acquiring through direct sales, you need a demo that works in a presentation. If you're acquiring through search, you need public-facing content. If you're acquiring through referral, you need the product itself to be shareable. These are not the same product.

What is the business model? Subscription? Per-seat? Usage-based? Marketplace take rate? This determines what the product needs to do to justify its cost, which determines which features matter and which are distractions.

What is the founder's actual unfair advantage here? Domain knowledge, existing relationships, distribution access, a problem they've personally lived. I want to know what makes this person the right person to build this specific product. If I can't find a good answer, I get cautious.

PsTally: the real problem was trust

When I was building PsTally, the stated problem was session logging for gaming lounges. Track which PS5 is active, how long, what the revenue was. That's a real problem. It's also a shallow framing of it.

The real problem I discovered once I was inside it was trust and visibility. Gaming lounge operators in Nairobi were hiring staff they couldn't supervise in real time. Revenue was leaking — not from theft necessarily, but from manual tracking errors, forgotten sessions, split payments that didn't get recorded. The owner who wasn't on-site had no reliable way to know what had actually happened that day.

The product I needed to build wasn't just a session timer. It was a source of truth that an operator could trust more than their staff's end-of-day report. That reframing changed what features mattered, what the dashboard had to communicate, and why a mobile-accessible owner view was non-negotiable from day one.

Stoka: the real problem was being present when you're not

Stoka is a boutique shop management system for small fashion and lifestyle retailers in Nairobi. The stated problem was inventory and sales tracking. That's accurate. It's also incomplete.

The shop owner's real problem was knowing the truth about her business when she wasn't there. She has a second location, or she's at a supplier, or she's home. Someone else is behind the counter. She doesn't know if the sales figure she'll hear at closing time is honest. She doesn't know if the stock she ordered arrived correctly. She doesn't know whether today was actually a good day or a managed version of it.

Stoka is the answer to that problem. Not inventory software. Presence at a distance. That reframe shaped the design language — the dashboard is calm, warm, and clear because it's communicating with someone who needs reliable information, not performance metrics. Those are different things.

The founders who skip these questions

I've learned to pay attention to what happens when a founder doesn't want to engage with these questions. Sometimes it's impatience — they're excited and they want to move. That's fine, I can work with energy. More concerning is when the reluctance comes from somewhere else: they haven't thought about it yet, or they have and the answers are uncomfortable.

The founders who can't describe their user specifically usually haven't talked to them yet. The founders who haven't thought about acquisition usually believe the product will sell itself. The founders who resist the business model question are sometimes still figuring out whether they're building a business or a portfolio piece.

None of these are disqualifying on their own. But they're signals. And the products built without answering these questions tend to solve the stated problem precisely — and the real problem not at all.

I'd rather spend two extra hours on these questions before writing a line of code than spend three months building the wrong thing well.