The five questions we ask before we quote anything
A project that goes badly rarely goes badly because someone wrote bad code. It goes badly because everyone agreed to build something without agreeing on what it had to be true for. We've learned to spend the first conversation on five questions, and to be willing to end the conversation there.
Who is holding this when it's working?
Not the buyer. The user. They're frequently different people, and the gap between them is where software goes to die.
On a construction platform we built, the answer was three different people with almost nothing in common: a project manager at a desk who needs dense invoicing and change-order screens, a homeowner who wants a calm view of progress without learning construction vocabulary, and a framer standing in the mud who needs to photograph a receipt with cold hands and get back to work. Build one interface for all three and you get software everybody tolerates and nobody likes.
Knowing that up front changed the architecture — one system of record underneath, three surfaces shaped entirely by who's holding them. Discovering it in month four would have meant rewriting the front end.
What does this have to be true for?
Every project has conditions it must survive. They are almost never in the brief.
An app for people taking notes during a talk has to work in a room with bad wifi, for someone who doesn't want to create an account before writing something down. That isn't a feature request, it's a constraint that reorders the whole build: offline becomes the default path and sync becomes the enhancement, rather than the reverse. Get that backwards and you ship something that shows a spinner at exactly the moment it's needed.
A tool that reads purchase orders has to survive vendors who each format their PDFs differently, and an OCR layer that turns zeros into the letter O. If you scope for the clean case, you have built a demo.
| Question | What the answer decides |
|---|---|
| Who is holding this? | Whether it's one interface or three |
| What must it be true for? | Whether offline is the default or the fallback |
| What if it's wrong? | Where the conservative code goes |
| Who owns it in a year? | Whether the content model is the product |
| Smallest useful version? | Whether we build it at all |
None of these are clever. They're just rarely asked before a number gets attached to the work.
What happens if this is wrong?
Software fails at different costs, and the cost should set the engineering posture.
A misaligned marketing page is embarrassing for an afternoon. A subcontractor payment that silently doesn't go through is a person who didn't get paid, and you find out days later from a phone call. A purchase order with one mistyped part number looks completely normal, ships, and surfaces weeks later on an invoice that doesn't match — at which point unwinding it means calling a customer and issuing a credit.
We ask this because it tells us where to spend the budget. The money paths and the data-integrity paths get the most conservative code we write: explicit state, no silent retries, reconciliation that assumes the network lied. The marketing page does not need that, and charging for it would be dishonest.
Who owns this in a year?
This is the question that most often changes what we recommend.
If the answer is "a marketing person who will need to change copy weekly," then the content model is the product and we should spend real time on it — an editing experience where an empty field falls back to something sensible rather than rendering a broken page. If the answer is "nobody, it's fire-and-forget," a CMS is overhead you'll pay for forever and we should say so.
If the answer is "another development team," then the deliverable includes documentation someone would actually read and a codebase that doesn't require us. Being easy to leave is the point. It's also, in our experience, why people stay.
What's the smallest version that's still worth having?
Not the MVP in the venture-capital sense. The smallest thing that would genuinely improve someone's week.
We ask because the answer is usually much smaller than the brief, and because building it first means the expensive decisions get made against real usage instead of assumptions. It also means that if the budget runs out — and sometimes it does — what exists is useful rather than half of something.
The corollary is that we sometimes talk people out of the build. If the smallest useful version is a spreadsheet and a recurring calendar reminder, that's the honest answer, and we'd rather give it than take a deposit for software that solves a problem someone doesn't have yet.
The question we used to skip
For a long time we didn't ask who owns this in a year, because it felt like a question about them rather than about the work. It isn't. It's the question that determines whether what we hand over survives contact with the people who inherit it.
We learned this the expensive way on content. Early on we'd build a site with the content model that made the code cleanest, hand it over, and watch a marketing person spend twenty minutes trying to change a headline that lived in three places. The model was correct and the software was wrong, because the person maintaining it wasn't in the design.
Now the editing experience is part of the scope rather than a thing that falls out of it. An empty field falls back to something sensible instead of rendering a broken page. Fields are grouped the way a person thinks about a page, not the way the database stores it. That costs real time up front and it's the difference between a site someone keeps current and one that quietly goes stale six months after launch.
Why this is worth an hour
None of these questions are clever. They're just rarely asked before a number gets attached to the work, because asking them risks shrinking the project.
That's the trade we've decided to make. A project scoped against real constraints costs what it costs and lands. A project scoped against a wish list costs more than the estimate, arrives late, and both sides remember it badly. We'd rather have the uncomfortable conversation while it's still cheap.