Before you sign a software quote, ask these 12 questions.
A plain-English checklist for spotting the omissions, vague promises and hand-offs that turn a sensible-looking software quote into an expensive surprise.
- Know what is missing before it becomes an invoice.
- Get the exact questions to send your agency or team.
- Tell a clear answer from a reassuring non-answer.
Written for the person signing off a build, not the person writing the code.
No spam. Unsubscribe anytime. How your data is handled.
The checklist opens the moment you submit. You'll also get The Founder's Tech Brief. Unsubscribe any time.
“He told me straight what my architecture could and couldn't carry, and why.”
Software builds rarely fail loudly. They fail as a run of small, reasonable-sounding decisions that nobody wrote down.
Average cost overrun across more than 5,400 IT projects studied by McKinsey with Oxford's BT Centre for Major Programme Management.
The same projects delivered a little over half the benefit their own business cases predicted.
Standish Group CHAOS data: roughly a third of software projects land as agreed, half arrive late or short, the rest are abandoned.
Sources: McKinsey & the University of Oxford and the Standish Group CHAOS benchmark. The McKinsey figures cover large enterprise programmes; the pattern shows up at every size, which is the point — small builds succeed far more often, and they succeed when the expectations were written down.
Nobody quotes you for the version that goes wrong.
Three things go wrong far more often than bad code does. All three are visible in the first conversation — if you know the sentence that exposes them.
I have been the person in that room on both sides of it: the one presenting the plan, and the one brought in afterwards to work out where it went.
The price didn't change. The scope did.
Nothing in the quote said “excluding data migration, third-party licences and whatever we find in week six.” It didn't have to. It simply wasn't in there — and everything not in there arrives later as a change request, at a rate nobody negotiated.
The demo always works.
Months of green status and encouraging screen shares, and still nothing running anywhere you can reach on your own. A demo is a rehearsal. Working software is a link you can open on your own phone while the person who built it is in a different room.
The team that pitched isn't the team that builds.
You met the founder, a delivery lead and a principal engineer. The work goes to whoever has capacity that month. Nobody told you when it changed, because nobody ever promised you it wouldn't.
Three places software quotes quietly move the risk to you.
You do not need to learn to read code. You need to know what to ask, what a usable answer contains, and when someone has avoided the question.
The contract and the quote
- “What is not included in this price?”
- “Who owns the code, and from when?”
- “What happens if this takes twice as long as you've said?”
- “What has to be true for this date to hold?”
The build and the people
- “Which named people will do the work, and what else are they on?”
- “Can you show me it running, not a demo?”
- “What did you decide this week that you'd have decided differently a month ago?”
- “If your lead developer resigned on Friday, what breaks?”
- “What are we building that we could buy?”
What procurement will ask you later
- “Where does customer data live, and who can read it?”
- “What happens when a customer sends us a security questionnaire?”
- “How do we get back to a working version of last Tuesday?”
Question 2 — “Who owns the code, and from when?”
Not “do we own the code” — they will say yes. From when. Many contracts transfer ownership on final payment, which means that during any dispute, the thing you are disputing about is theirs.
Cites the clause and says what happens on termination — including whether you get the repository, the infrastructure config and the deployment access, or only the source files.
“It's all yours, don't worry about that.” Ask them to point at the sentence. If nobody can find the sentence, that is the finding.
Eleven more in the same format — each with the answer that settles it and the answer that doesn't.
Every reason founders skip this, and what each one costs.
“AI writes the code now — surely a build is quick and cheap.”
Code was never the expensive part. AI made producing code faster. It did not make deciding what to build, owning it, running it, securing it or being accountable for it faster — and that is where software money actually goes.
Google's 2025 DORA report puts AI use at around 90% of teams, and finds that higher AI adoption correlates with more delivery instability: more failed changes, more rework, longer to recover. Faster to write is not the same as safer to ship.
It also changed one thing specifically against the buyer. A supplier can now put something in front of you that looks finished far earlier than it is. Which makes “show me it running, not a demo” a sharper question than it was two years ago, not a redundant one.
Source: Google Cloud, 2025 DORA State of DevOps report. And not one of the twelve questions is about code. They are about who owns it, who is accountable, where the data sits, and what happens when somebody leaves — none of which a model generates for you.
“They came recommended.”
A recommendation tells you they delivered somebody else's scope, with whichever engineers happened to be free that quarter. Neither of those transfers to you. And a supplier worth the recommendation answers all twelve without flinching — so you lose nothing by asking.
“It's a small build.”
Small builds do succeed far more often, and they succeed because the expectations were small enough to write down. The failure mode for a small build isn't collapse, it's the change request: the price holds, the scope moves, and by the third one you are funding a rebuild nobody ever proposed.
“I already have a technical co-founder.”
Then hand them the list — twelve quick answers and a good afternoon. Worth knowing: being able to build software and having been on the buying side of a supplier contract are different experiences, and most technical founders have only had the first.
“My lawyer reads the contract.”
Keep your lawyer. They will tell you the IP clause is standard, and it is. They will not tell you that ownership “on final payment” means that during any dispute, the thing you are disputing over is theirs — or that the delivery date has no stated dependencies anywhere in the document.
“I'll get three quotes and compare.”
Three quotes tell you who is cheapest at describing the work. They cannot tell you which one has priced the parts missing from all three. The questions are what make three quotes comparable in the first place.
“I don't have time — I'm signing this week.”
It is eight minutes. If eight minutes of questions changes whether you sign, that is the best-value eight minutes in the whole project.
Eight minutes to read. One call to use it on.
Before the call
Read it once — about eight minutes — and mark the three or four questions your quote already leaves open.
On the call
Ask them out loud, in order, and write the answers down close to word for word. The questions are short on purpose: they are difficult to answer sideways.
Afterwards
Put what you wrote next to what a real answer contains. The distance between the two is your negotiation — and you have it in writing before you have committed to anything.
“I had a founder-built prototype, a pre-seed conversation weeks away, and nobody technical who could answer for either of them. Mayur told me straight what my architecture could and couldn't carry, and why — then took it to production, hired our three founding engineers and sat on the investor calls as the technical counterparty. We rebranded mid-raise and closed the round.”
The full engagement is written up, decisions and trade-offs included, in the Everwise case study.
Worth eight minutes, and when it is not.
If somebody already in the room can ask all twelve and knows what a real answer sounds like, you do not need this. Most teams at this stage do not have that person yet.
It suits you if
- You have a quote, a proposal or a statement of work in front of you, and a date by which you have to decide.
- You are accountable for the build without being the person making the technical calls.
- You have been through one build that went sideways and you still cannot name exactly where.
- The team is in-house, and you want the same questions asked of your own people.
It will not help if
- You want the answers verified rather than heard. That takes someone reading the code, the contract and the architecture.
- You are looking for a template contract. These are questions to ask, not clauses to sign.
- You want somebody to run the conversation for you. This puts the questions in your hands, not mine.
What this cannot do
It will tell you whether you are being answered or handled. It will not tell you whether the answers are correct — that takes someone who can read the code, the contract and the architecture, and who is not selling you the build.
If you get through the twelve and still can't tell, that is what The Second Opinion is for.
Mayur Kale — hands-on fractional CTO
Ten years from pre-seed to national-scale platforms, on both sides of the Atlantic. I write the code, read the contracts and sit on the calls — which is where every one of these twelve questions came from. I don't build for the agencies you would be asking them of.
Several of them came out of codebases I inherited from somebody else, where the answer to “who owns this” or “where does the data live” turned out to be nobody's job to know.
More about how I work
The questions people ask me about this one.
- Is it actually free?
- Yes. No card, no call, no trial. You give an email address, the twelve questions arrive, and The Founder's Tech Brief follows every couple of weeks. One click unsubscribes, and you keep the checklist either way.
- I can't read code. Is this written for me?
- It is written for exactly that person — the one signing the contract, not the one writing the software. There is no code in it, and no jargon you would have to look up. Every question is a single sentence you can read straight off your phone.
- Won't this make my agency defensive?
- A supplier worth hiring is glad to be asked, because they have answers and being asked is what makes those answers count. If “who owns the code” makes somebody bristle, you have just learned something the quote was never going to tell you.
- I have already signed. Is it too late?
- No. The nine questions about the build, the people and what procurement asks later all work on a project already in flight. And renewals, change requests and phase twos are contracts too — so the first three come round again.
- What happens to my email address?
- It goes onto my newsletter list and nowhere else. No sales sequence, no reselling, no sharing with anyone. You can reply to any edition — they come to me, and I read them.
- Is this AI-generated filler?
- No. Every question came out of a real engagement — a contract I read, a call I sat on, or a build I inherited from somebody else. If a question is on the list, it is because something went wrong somewhere in the absence of it.
- Twelve questions. Is that all?
- Yes, and that is the design. A hundred-point audit template is one you never actually run. Twelve fit on one screen and inside one call — which is the only version that gets used, and a checklist that gets used beats a thorough one that doesn't.
- Are you going to pitch me a build?
- Not off the back of this. If you get through the twelve and still cannot tell whether the answers are correct, that is a separate piece of paid work, and the checklist says so plainly rather than hiding it at the end.
Get the questions before the quote becomes a commitment.
Keep it beside you while you read the quote, speak to the agency, or take it back to your own team.
- No card, no call
- Opens straight away
- One click to unsubscribe
Would rather just talk it through? How the engagements work