What Every Section of a Dev Proposal Is Really Asking You to Sign

Published by CodeNicely, the product studio founded by Meghal Agrawal and Ujjwal Agrawal in 2017

For: A UK SMB owner or COO who has received two or three competing dev proposals totalling £80k–£300k, has no in-house engineering lead to sense-check them, and cannot tell whether the differences in price reflect genuine scope differences or vendor risk-padding

The most expensive clause in a software development proposal is almost never the price. It is the change-control mechanism — because a vague scope statement combined with a modest-looking day rate for change requests is how a £120k fixed-price engagement becomes a £210k invoice without the vendor ever breaching the contract. If you are a UK SMB owner holding two or three polished proposals and no engineering lead to decode them, this is the interview prep: the questions to ask each vendor, why they matter, and how to tell a confident answer from a rehearsed one.

Context on why this matters: 66% of enterprise software projects run over budget according to McKinsey and the University of Oxford's study of 5,400+ IT projects. PMI data shows 52% of projects experience uncontrolled scope changes, with an average 27% budget overrun directly attributable to scope creep. And Standish Group's 2023 CHAOS benchmark found 92% of organisations named scope creep a top failure cause — but only 38% had a formal process to manage it. Your proposal is where that process either exists or does not.

Before you call: the three proposals, side by side

Print all of them. Mark up every section where the three vendors disagree on scope, acceptance, IP, or change control — those are the sections where the real price is hiding. The questions below are the ones you take into the follow-up call.

Scope of work: what you are actually buying

1. "Can you restate the scope in terms of user outcomes, not features?"

Why it matters: A feature list ("user login, admin dashboard, Stripe integration") is almost impossible to argue about later. An outcome ("a returning customer can reorder their last prescription in under 60 seconds") either works or it does not.

Good answer: The vendor reframes without hesitation — they have already thought in outcomes and the feature list is a translation layer for your procurement team.

Red flag: They push back that outcomes are "too subjective to contract against." That is the sound of a vendor who wants acceptance to be checkbox-based so they can hand over something that technically ships but does not work.

2. "Which items in this scope are assumptions, and what happens if an assumption is wrong?"

Why it matters: Every proposal is built on assumptions — about your existing data quality, your users' devices, the third-party APIs you already have, your internal review turnaround. Buried assumptions are the single most common source of change orders.

Good answer: They can produce a numbered assumptions list within 10 seconds and walk you through what each one means in pounds if it turns out to be wrong.

Red flag: "Don't worry, we'll handle it as we go." You will handle it. On an invoice.

3. "What is explicitly out of scope?"

Why it matters: A proposal with no "out of scope" section is not a tightly-defined proposal — it is a loosely-defined one dressed up to look tight. Honest vendors list exclusions because exclusions protect both sides from an awkward conversation in month four.

Good answer: A specific exclusions list: "migration of historical data pre-2022, SSO integration beyond Google Workspace, native mobile apps, accessibility audit to WCAG 2.2 AA."

Red flag: "Everything you need is included." Nothing is ever everything you need.

Timeline and milestones: what the dates actually mean

4. "Which milestones trigger a payment, and what is the acceptance test for each?"

Why it matters: If a milestone is "Phase 2 complete" with no acceptance criteria attached, you have no leverage to withhold payment when Phase 2 is 80% complete.

Good answer: Each milestone has a written acceptance test — a demo script, a checklist, a specific user journey that must work end to end on a staging environment you can access.

Red flag: Payment is tied to calendar dates rather than deliverable acceptance. That inverts the risk: you pay regardless of whether the work is usable.

5. "What is your contingency assumption, and is it inside the quoted number or outside it?"

Why it matters: Serious vendors price in 15–25% contingency on fixed-price work. The question is whether they absorb it or bill it. Given that large IT programmes run 45% over budget on average (McKinsey/Oxford), someone is absorbing that risk — find out who.

Good answer: "Contingency is inside the fixed price. If we burn through it, that is our problem unless scope changes."

Red flag: No contingency conversation at all, or a confident claim of zero contingency on a six-month build. That means the overrun is coming to you as a change order.

Change control: the clause that decides everything

6. "Walk me through exactly how a change request becomes a signed variation."

Why it matters: This is the clause that converts your fixed price into a time-and-materials engagement in slow motion. The mechanics matter: who can raise a change, who approves it, how it is estimated, whether work pauses while you decide.

Good answer: A written process. Changes are logged, estimated in writing with a fixed-price impact (not just a day-rate), signed by a named person on your side, and queued — not started — until signed. There is a stated threshold (e.g. anything under 2 days of effort is absorbed) so you are not nickel-and-dimed on tiny asks.

Red flag: "We'll just track it against the day rate and reconcile at the end of the phase." This is how £120k becomes £200k. Also watch for change requests that can be "verbally approved" by anyone on your team — a developer agreeing to a feature in Slack should not trigger a billable variation.

7. "What is the smallest change you have ever charged for, and the biggest change you have ever absorbed?"

Why it matters: It forces them off the script. The answers tell you what their actual change-control culture is, not what their contract template says.

Good answer: Specific stories. "We absorbed a two-week redesign on a project last year because our discovery missed a user segment — that was our miss. We charged for a one-day copy change on another because the client's marketing team kept rewriting it weekly."

Red flag: Vague generalities, or an inability to recall ever absorbing anything.

Acceptance, warranty, and what "done" means

8. "What is the warranty period after go-live, and what does it cover?"

Why it matters: "Bug fixes for 30 days" sounds reasonable until you realise "bug" is undefined. If the vendor defines a bug as "behaviour that contradicts the written spec" and the spec is thin, almost nothing qualifies.

Good answer: 60–90 day warranty, with "bug" defined as any defect that prevents a documented user journey from completing successfully, regardless of whether that journey was explicitly specified.

Red flag: A 30-day warranty with a tight bug definition and a separate "support contract" quoted alongside. You are being sold the fix for the problem they are about to deliver.

9. "What is the handover package — specifically?"

Why it matters: "Full documentation and source code" means nothing. You need to know what you can hand to a different vendor on day one of month seven and have them productive within a week.

Good answer: A specific list: Git repository with full history, README with local setup instructions, environment variable documentation, deployment runbook, architecture diagram, API documentation, database schema with migration history, list of third-party services and credentials, known issues log.

Red flag: "We'll put together whatever you need at the end." That is a lock-in strategy.

IP, ownership, and the clause UK buyers get wrong

10. "Does the contract contain an express written assignment of copyright to us, effective on each payment?"

Why it matters: Under the UK Copyright, Designs and Patents Act 1988, the developer owns the copyright in software they write by default — not the client who paid for it. Paying an invoice transfers no copyright. You need an express written assignment, and ideally one that vests ownership as each payment is made, not at final sign-off (so a dispute mid-project does not leave you with no rights to code you have already paid for).

Good answer: They point to the exact clause, confirm assignment is on payment of each invoice, and are relaxed about it. (This is a legal matter — have a solicitor review the actual wording.)

Red flag: "You own everything once the project is complete" without a written assignment clause, or ownership that only transfers on final payment. Also watch for broad carve-outs where the vendor retains rights to "frameworks" or "libraries" they developed — ask what that covers in practice.

11. "What open-source licences will be in the final codebase, and are any copyleft (GPL/AGPL)?"

Why it matters: AGPL code in a SaaS product can oblige you to release your own source. Most vendors will not introduce this deliberately, but you want them to have a licence policy, not a shrug.

Good answer: They run a licence scanner (FOSSA, Snyk, GitHub's dependency review) and can produce an SBOM on request.

Red flag: Blank stare, or "all our code is open-source friendly."

The team you are actually getting

12. "Name the people who will do the work, and tell me what percentage of their time is on our project."

Why it matters: Proposals often feature senior architects in the pitch who then disappear once the contract is signed, replaced by whoever is on the bench. Fractional allocations also matter — a "full-stack engineer at 40%" is a different project than "at 100%."

Good answer: Named individuals, LinkedIn profiles on request, stated allocations, and a commitment that any substitution requires your written approval.

Red flag: "Our team will be assigned at kickoff based on availability." You are buying a lottery ticket.

13. "Where will the work be done, and in which timezone will stand-ups run?"

Why it matters: For an offshore development proposal review, timezone overlap is a real cost. Four hours of overlap is workable; one hour is not.

Good answer: Specific overlap window, named communication channels, a UK-hours point of contact for escalations.

Red flag: "Async-first" used as a cover for "we will respond when we respond."

Security, data, and the review you cannot skip

14. "How is our data handled during development, and where does it sit?"

Why it matters: If you are regulated (health, finance, legal) or handle personal data, the vendor's dev environment is your dev environment for UK GDPR purposes. Production data in a developer's laptop in a non-adequate jurisdiction is your breach.

Good answer: Synthetic or anonymised data in dev and staging. Production access is restricted, logged, and limited to named individuals. Data residency is stated.

Red flag: "We copy a snapshot of your production database into our dev environment to make testing realistic." That is a GDPR incident waiting to happen.

15. "What is your incident response SLA during the warranty period, and what counts as P1?"

Why it matters: "Best-effort response" is not an SLA. You need clock-time commitments tied to severity definitions you agree with.

Good answer: P1 (service down) response within 1 hour during business hours, 4 hours out of hours; defined escalation path; named on-call contact.

Red flag: SLAs that only kick in under a separate paid support agreement that was not mentioned in the main proposal.

Reference calls: the questions people forget to ask

16. "Can I speak to a client whose project went badly, or had a difficult patch?"

Why it matters: Every vendor can produce a happy reference. The real signal is whether they can produce a client who had a rough stretch and will still take the call — that tells you how they behave when things go wrong, which is the only thing that matters once the contract is signed.

Good answer: They offer one, with a brief honest summary of what went wrong and what they did about it.

Red flag: "All our projects go smoothly." On a planet where only 16.2% of software projects finish on time and on budget (Standish 2023), that is statistically improbable.

17. "On your reference calls, what did the client say they would do differently next time?"

Why it matters: Ask this directly on the reference call itself. The answer tells you what the vendor's weak spot is, in the client's own words, without the vendor filtering it.

How CodeNicely can help

If you are an SMB or scaleup trying to decode competing proposals before signing, the most useful thing we can do is a paid short-form review of the proposals you have — scope statement, change control, acceptance criteria, IP clause — against the questions above. That costs a fraction of the engagement and often changes what you negotiate before signing, regardless of who you pick.

If you are weighing us as one of those vendors: the engagement most similar to a tightly-scoped SMB build is GimBooks, a YC-backed accounting SaaS where the scope statement explicitly separated the invoicing core (fixed-price, fixed-acceptance) from the GST-filing module (phased, with a defined re-scoping point after user research). That structure — a hard-contracted core and a lightly-contracted exploratory layer — is often the honest answer when a buyer wants a fixed price but the problem is genuinely not fully knowable upfront. For regulated-data builds, HealthPotli is the closer analogue: synthetic data in all non-production environments, production access logged and restricted. See our SMB engagement model for how we structure proposals.

The one thing to take into every proposal call

Read the change-control clause first, the acceptance criteria second, the IP assignment third. The price table is downstream of all three. A low number attached to loose scope, soft acceptance, and ambiguous IP is more expensive than a high number attached to tight versions of all three — the data on scope creep overruns is unambiguous on this. Get a solicitor to review the final contract before signing; the questions above help you negotiate, but they do not replace legal advice.

Frequently Asked Questions

How long should a software development proposal be?

Length is not the signal — specificity is. A tight 8-page proposal with a numbered scope, written acceptance criteria, a change-control process, and an IP assignment clause is more valuable than a 30-page proposal padded with methodology diagrams and team bios. If you cannot find the acceptance test for a milestone in under 30 seconds, the proposal is too vague regardless of its page count.

What does a dev proposal typically cost to produce, and should I pay for one?

Serious vendors spend 20–80 hours producing a fixed-price proposal for a mid-sized engagement, which is why most will not do unlimited free proposals. For projects above roughly £100k, a paid discovery phase (a few thousand pounds, a few weeks) usually produces a far more accurate scope and price than a free proposal based on a one-hour briefing — and the discovery output is yours to shop around. What turns a rough range into a real quote is a documented scope, a decision on fixed-price versus time-and-materials, and clarity on how much existing data and how many third-party integrations are in play.

Why do three vendors quote wildly different prices for the same brief?

Usually because they are not quoting the same thing. One has assumed you have clean data, another has not. One has priced in a 20% contingency, another has priced to win and plans to recover margin through change orders. One is quoting a senior team at 100% allocation, another a mixed team at 40%. Line the scope-of-work sections up side by side before comparing the price lines; the gap almost always disappears into assumption differences.

Is a fixed-price contract safer than time-and-materials for an SMB?

Fixed-price shifts risk to the vendor only if the scope is genuinely fixed and the acceptance criteria are tight. If either is loose, fixed-price simply means you pay a risk premium upfront and still pay change orders later — the worst of both. Time-and-materials with a weekly burn cap and a monthly re-planning cadence is often safer for genuinely exploratory work; fixed-price is right for well-understood builds with clear acceptance tests.

Do I legally own the code if I have paid for it in full?

Not automatically, under UK law. The Copyright, Designs and Patents Act 1988 gives first ownership of copyright to the author (the developer), not the person who commissioned the work, unless there is an express written assignment. Paying the invoice is not enough. Have a solicitor confirm the assignment clause in your specific contract — this is a question for a lawyer, not a blog post.