The most valuable meeting of one of our recent projects produced no estimates, no timelines and no architecture. Just questions.
A funded e-commerce startup had come to us with the full 2026 set: an online sales platform, an AI assistant, AI-powered search, AI analysis of orders. A tight budget, and behind it investors waiting for proof that the business works.
The easy move would have been to scope the wishlist, price it and start the sprints – that’s what the market expects, and it’s what gets projects moving fast. We spent the first two weeks on business analysis instead. I’ll be honest: earlier in my career, discovery looked to me like a phase to tolerate on the way to the sprint board. This project is a neat reminder of why it isn’t.
The questions that mattered more than the spec
We didn’t ask about features. We asked about the business those features were supposed to serve.
How will sales actually happen? Purely online, or does half of it close through managers in chats and DMs? If a large share of revenue closes in conversations, the platform’s job isn’t “sell everything” — it’s “support the sale.” That reframes the feature list from day one: the CRM your managers live in matters more than the fifth checkout optimization.
What’s the realistic order volume for the first six months? A hundred orders a day and ten thousand a day need two very different platforms, and only one of them fits this budget. Architecture is a financial decision as much as a technical one — and deferring the expensive option until revenue proves it isn’t cutting corners, it’s risk management.
Who is the end customer, and what do they actually need? Not the persona slide — the actual person, their actual problem, and the moment they decide to pay.
What exactly do your investors need to see at the next round? Growth numbers? Conversion? One impressive demo? Founders rarely hear this question from vendors, and it’s the most important one: for a funded startup, an MVP is a fundraising instrument as much as a product.
An MVP isn't a small version of the final product. It's the cheapest possible answer to the question your business needs answered - and for a funded startup, that question belongs to the investors as much as to the users.
The questions that mattered more than the spec
The answers cut the scope roughly in 35%.
A modest forecast meant a boring monolith and managed Postgres instead of a microservices dream. If orders grow tenfold, we’ll have the revenue to re-architect — and the logs to know exactly where. Today, every dollar spent on infrastructure flexibility is a dollar not spent on learning.
The “AI order analysis” turned out to be really for the investors, so it became a thin, honest reporting layer over clean data — not an ML pipeline nobody would maintain. The assistant and the search stayed, because they carry the demo. The loyalty program and the mobile app [замени на то, что реально срезали] went to the “deliberately not building” list.
That list deserves the same respect as the roadmap. Everything we didn’t build is a part of why we shipped on budget.
What a coding round shows — and what it misses
| Signal | Visible in a coding round | Cost if missed |
|---|---|---|
| Ownership of decisions | Rarely | Weeks of rework after silent disagreements |
| Talking to non-technical stakeholders | No | Missed requirements and extra calls |
| Handover habits | No | Context lost when the engineer rotates |
Based on our replacement cases.
The demo is a feature too
Users need a product that works. Investors need evidence that the business works. These are different requirements, and an MVP that serves only the first one runs out of runway before either audience is satisfied.
The AI assistant stayed in our scope not because early users demanded it — there were no users yet — but because in this market it was the moment of the demo that made the next round easier. That’s a legitimate product reason. Pretending otherwise would have been dishonest planning, and cutting it to “save budget” would have been a false economy.
From the very begning to the release
Funded e-commerce startup; wishlist: sales platform + AI assistant + AI search + AI order analysis; fixed budget; investors waiting for proof.
What was done. Two weeks of business analysis before any commitment — sales model, forecast scenarios, customer profile, investor expectations. Scope cut by ~35%. Architecture matched to the forecast instead of the fears.
Results. MVP shipped inside the budget; the investors saw exactly what the next round needed.
What to do on Monday
The checklist we run before agreeing on any MVP scope
They take ten minutes and show what a coding round cannot.
-
Who is this MVP for?
Who is this MVP for — users, investors, or both?
-
What must be demonstrably true in six months
What must be demonstrably true in six months for the next round to happen?
-
What's the realistic volume.
What's the realistic volume - orders, traffic, data? This dictates the architecture, not the other way around.
-
How do sales actually close?
How do sales actually close - product-led or human-led?
-
What result would make us throw this scope away?
What's the most expensive question you didn't ask at the start of a project?
If you're having hard times to hire "the right one" developer for your project, book a call - after we align on the role, we'll send 2-3 candidates pre-vetted by stack, product, and culture within ~60 hours.
