Most bad software projects were mispriced before a line of code existed. Not because anyone lied, but because the conversation that produced the number was forty minutes long and mostly about features.
Features are the easy part. Here is what actually decides whether a project lands where it was quoted.
What happens if this is late?
Ask it directly. The answer sorts projects into two kinds.
Sometimes late means mildly annoying. Sometimes it means a contract renewal is missed, a grant reporting deadline is blown, or a team runs a manual process for another quarter. Those are different projects with the same feature list, and they need different amounts of contingency and different release strategies.
If nobody can say what late costs, the deadline is decorative and you should treat it that way.
Who has to approve this, and have they seen it?
The most reliable predictor of a project going sideways is a stakeholder who appears in week six. They have opinions, those opinions are legitimate, and they were never in the room.
Ask who signs off. Ask whether that person has seen the requirements. If the answer is “I’ll handle them,” expect a round of changes that nobody budgeted.
What does this replace?
Almost nothing is built into a vacuum. There is a spreadsheet, a WhatsApp group, a paper form, an old system nobody likes.
You need to see it. The spreadsheet contains the real business rules — including
the ones nobody remembers deciding and everybody depends on. A column called
status_2 with four possible values is a workflow, and it will not appear in any
requirements document — any more than
the parts of an inherited codebase that are not in version control
appear in its repository.
Where does the data come from and where does it go?
Integrations are where estimates die. “It should sync with our accounting software” is one sentence and can be anything from an afternoon to a month depending on whether that software has an API, whether anyone has the credentials, and whether the vendor charges for access.
Ask for the name of every system this must talk to. Then ask who administers each one, because that person is now on your critical path.
Who maintains this after launch?
If the answer is nobody, that changes what you should build. A system that will be maintained by a small team should be boring, well-documented and unexciting. A system with a dedicated engineer can afford more.
Building something clever for a client who has nobody to look after it is a disservice dressed as generosity.
What is genuinely out of scope?
Not “what’s in scope” — everyone can list that. Ask what is deliberately not being built, and write it down in the proposal.
An explicit out-of-scope list is the single cheapest protection against scope creep, because it converts an awkward conversation in month two into a sentence somebody already read and agreed to.
The one that predicts the most
“Has a project like this failed here before?”
If yes, find out what happened. Sometimes it was the vendor. Often it was something structural — the data was never as clean as claimed, the approvals never came, the internal champion left. Whatever it was, it is probably still there, and it will happen to you too unless it is named out loud.
People answer this question honestly more often than you would expect. It is just rarely asked.
What this costs you
An hour, maybe two. Against a project where the estimate holds, which is worth considerably more than an hour to both sides.
The quote that arrives twenty minutes after a call is not fast. It is a guess with a decimal point.
We run a paid discovery session before quoting anything substantial — you get the written scope whether or not you build it with us. Tell us what you’re planning.