I've been a business analyst, a developer, and an architect. I've seen projects fail at every level. And here's what I've learned: the most expensive mistakes happen before anyone writes a line of code.
Not because the code is bad. Because we built the wrong thing.
An AI can generate code in seconds. But it can only build what you ask for. If your understanding of the problem is incomplete, the AI will efficiently build you the wrong solution. You'll ship faster than ever—and still end up rebuilding.
Before I start any project—whether I'm vibe coding a prototype or architecting an enterprise system—I answer these ten questions. They've saved me (and my clients) more time and money than any programming skill ever has.
1. Who exactly is this for?
Not "users" or "customers." Specific people with specific needs.
A booking system for a yoga studio serves different people: the studio owner managing schedules, instructors viewing their classes, customers booking sessions. Each has different needs, different contexts, different definitions of "working software."
Why it matters: If you don't know who you're building for, you'll optimise for the wrong things. The studio owner needs reporting. The customer needs a fast booking flow. Building for "the user" gets you neither.
What to write down: Names (or persona names), their role, what they're trying to accomplish, how they'll use this.
2. What problem are we actually solving?
"I need a website" is not a problem. "Customers can't book outside business hours and I'm losing sales" is a problem.
The first leads to scope creep and feature bloat. The second has a clear success metric: did bookings increase outside business hours?
Why it matters: The problem definition shapes every decision that follows. It's also how you'll know when to stop building. Without it, projects expand indefinitely.
What to write down: The problem in one sentence. The impact if we don't solve it. The evidence that this problem exists.
3. How do they solve this today?
Every problem you're solving has a current solution—even if that solution is "they don't, and they suffer."
A client wanted a custom inventory system. When I asked how they managed inventory now, the answer was "a spreadsheet Carol updates every morning." That spreadsheet became the requirements document. It showed exactly what data they tracked, what calculations they needed, what views they looked at.
Why it matters: The current solution shows you what actually matters to users. It also reveals the switching cost—if your solution isn't significantly better than what they have, they won't adopt it.
What to write down: Current process, tools used, pain points, workarounds.
4. What does success look like?
"A working app" is not success criteria. Success is measurable outcomes.
- •Booking conversion rate increases from 20% to 35%
- •Support tickets about X drop by half
- •Time to complete process Y goes from 30 minutes to 5
Why it matters: Without clear success metrics, you'll keep adding features hoping one of them helps. With them, you can ship the minimum that moves the needle and iterate from there.
What to write down: 2-3 specific, measurable outcomes. Timeframe to evaluate them.
5. What's the smallest thing we could build?
This is the question most people skip—and the one that saves the most money.
You don't need the full vision in version one. You need the smallest version that tests your core assumption. Often that's embarrassingly simple.
A founder wanted a marketplace platform. After this discussion, we realised the core assumption was "contractors in this niche want more work and will pay for leads." We tested it with a Google Form and manual matching. Two weeks and zero code proved the concept. Then we built the platform.
Why it matters: Building the full vision before validating the core is the classic startup failure mode. You burn runway on features for a problem that might not exist.
What to write down: Core assumption. Smallest test of that assumption. What you'd learn from it.
6. What data do we need, and where does it come from?
Every application is ultimately data transformation. You need to understand:
- •What data enters the system?
- •Where does it come from?
- •What format is it in?
- •How clean/reliable is it?
- •What data do we create?
- •Where does it need to go?
I've seen projects stall for weeks because nobody realised the "product catalog" was actually three spreadsheets, a legacy database, and "whatever Dave remembers."
Why it matters: Data integration is usually the hardest part of any project. If you don't understand it upfront, you'll discover the complexity at the worst possible time.
What to write down: Data sources, formats, quality issues, integration requirements.
7. What are the critical paths?
Some parts of your system matter more than others. In an e-commerce site:
- •Browse products → Nice to have
- •Complete checkout → Critical
- •Inventory sync → Critical
- •Product recommendations → Enhancement
Critical paths need bulletproof implementation. They get the testing, the error handling, the architectural attention. Non-critical paths can be simpler.
Why it matters: You can't give everything equal attention. Knowing what's critical helps you allocate effort correctly and make tradeoff decisions.
What to write down: Critical paths ranked by importance. What failure in each would mean.
8. What's the worst that could happen?
Security breaches. Data loss. Legal liability. Angry customers.
For a hobby project, worst case is embarrassment. For a healthcare app, worst case is harming patients. The difference should shape every technical decision.
Why it matters: This determines how much caution is appropriate. It's the counter-balance to "move fast." Sometimes moving fast is right. Sometimes it's reckless.
What to write down: Worst case scenarios. Their likelihood. Their impact. What we'd do if they happened.
9. Who else needs to be involved?
Software projects rarely exist in isolation. Consider:
- •Who needs to approve this?
- •Who will support users?
- •Who maintains it after launch?
- •What other systems does it affect?
- •Who has knowledge we need?
I've seen finished projects sit unused because nobody got buy-in from the operations team who'd need to change their workflow.
Why it matters: Stakeholder surprises kill projects. Better to have the hard conversations before you've built something.
What to write down: All stakeholders, their interest/concerns, when to involve them.
10. What happens in six months?
The first version is just the beginning. Consider:
- •Will we want to add features?
- •Will usage grow?
- •Will we need to integrate with other things?
- •Will we need to hand this off to someone else?
If the answer to any of these is yes, it should influence technical decisions today. Patterns that work for a static project become painful for an evolving one.
Why it matters: Short-term decisions create long-term constraints. Understanding the trajectory helps make better tradeoffs.
What to write down: Expected evolution. Growth predictions. Known future requirements.
Using this framework
You don't need perfect answers to all ten questions. You need to have asked them.
The act of asking reveals gaps in your understanding. "I don't know" is a valuable answer—it tells you what to research before building.
I keep these questions as a checklist. Before any project kicks off, I work through them with stakeholders. The document that results becomes the foundation for everything that follows.
It's not glamorous work. You're not shipping features. But it's where the real leverage is.
Building the right thing adequately beats building the wrong thing perfectly. Every time.
The shortcut
If you don't have time for all ten, at minimum answer these three:
1. Who exactly is this for? 2. What problem are we actually solving? 3. What does success look like?
Get those right, and you can course-correct the rest. Get them wrong, and no amount of good code will save you.
The best AI in the world can only build what you ask for. Make sure you're asking for the right thing.