Why do software projects fail?
Most of them fail before anyone writes a line of code. The engineering is usually fine. The problem the software was built to solve was never defined properly, so the finished system answers a slightly different question, and everybody finds that out after the money is gone. The fix is not better developers. It is a harder conversation at the start.
It rarely announces itself that way. It shows up as bugs, slipped deadlines, a redesign eight weeks after launch, or a system the staff quietly stop using. Those are symptoms of a decision made too early on too little information, and everything built afterwards inherits it.
Most briefs arrive as a solution
"We need an app." "We need a booking system." "We need a dashboard." Each of those is an answer, and none of them is a problem. That is not a criticism, it is how people describe what they want. But if nobody separates the two, the agency builds the sentence instead of the outcome behind it, and both sides stay happy until launch.
So the first question is never about features. It is this: if we build nothing, what does that cost you over the next year? A specific answer means the project is real. A vague one means it is not ready to be quoted, and scoping detail will not hide that later.
The questions we ask before we quote
These come up on the discovery call, before any number exists. About an hour, and the cheapest hour in the project.
What breaks today, and who feels it?
Hours lost, enquiries missed, invoices sent late, one person holding the whole process in their head. Put it in something countable. "It is inefficient" is not a target. "We lose about ten hours a week capturing the same order twice" is, and you can measure whether the software moved it.
Who uses this, and on what kind of day?
Software gets used by real people under real pressure, not by a persona on a slide. A parent choosing a daycare on their phone at ten at night. A plumber with wet hands standing in someone's kitchen. An admin clerk with forty of these to get through before lunch. Each of those produces a different product, and only one of them is right.
What does the process look like right now?
Whatever a business does today works well enough to keep it running, and the odd steps usually have good reasons behind them. Walk it end to end before replacing it. Half of what looks like waste is a control someone added after being burnt once, and stripping it out is how a better system becomes the one nobody trusts.
What is the smallest version worth having?
Not the cheapest version. The smallest one that changes something in the business the week it goes live. Everything else follows once real people have used it. The order in which capability arrives is a decision, not a byproduct of what was easiest to build first.
What has to be true on day one?
The unglamorous constraints. What it has to talk to, what data cannot move, who must not see what, which regulation applies, what happens when the connection drops, who maintains it in two years. Cheap to design around at the start, expensive to retrofit. Most of the painful rebuilds we get called into started right here, which is also why we keep to a boring default stack.
An hourly agency can afford a vague brief. A fixed-price one cannot.
Three projects where the answer changed the build
The constraint that mattered was that the staff running admissions are not technical, so anything that did not make immediate sense would be back on paper within a month. That shaped the admin more than any visual decision did.
Read the case study →Visitors were leaving because they could not tell what a clean would cost or whether the business covered their suburb. Pricing and service areas were the product, not the design.
Read the case study →The question worth asking was when their customers have the problem, which is at midnight with water coming through a ceiling. That answer decided the entire flow.
Read the case study →Why we ask more than most
Partly because it produces better software. Mostly because we quote a fixed price. If we misunderstand the problem, we absorb the cost of putting it right, not you. The incentive sits where it belongs: understand it now, or pay for it later out of our own margin.
It is also why we turn work down. A project nobody can describe clearly is not a project yet, and it rarely lands on either of the two problems worth paying to solve.
What to do with this before you hire anyone
Write your answers down first, in your own words, on one page. It costs an evening and changes what you get back from every agency you speak to.
Then use the questions as your filter. Anyone who hands you a number without asking what this costs you today, who uses it, and what it has to fit into is pricing your sentence rather than your problem. What an agency asks before quoting tells you more than a portfolio does.
Good custom software is not mainly a technical achievement. The technical part is what we can promise. The valuable part is arriving at the right thing to build, and that gets decided long before anyone opens an editor.
This piece started with an article in BusinessTech making the same argument. That it still needs saying is the point.
Not sure the brief is right yet?
Bring us the problem rather than the spec. Within 48 hours of the call you get what we would build, what we would leave out, and what it costs.
Book a Discovery Call