Inside fixed bid software project scoping, the complete operator guide

Fixed bid software project scoping is the practice of converting a client's intent into a contract that locks scope, timeline, and price before a single line of production code is written. It is the most consequential conversation in any agency engagement: every later argument about delivery turns on a sentence written here. La Boétie has scoped fixed-bid work across finance, legal, auctions, insurance, psychology, and community platforms since 2020, and we hold a sharp house position on which projects belong inside this model, which projects must be refused, and what a real discovery phase looks like once you stop calling kickoff workshops by that name.

This pillar maps the whole hub. We tell you which sibling article to read first depending on your starting condition, what the studio recommends at each fork, and where we disagree with the industry consensus. Read this one once; then go deep on the focal articles that match your engagement.

Key takeaways

• On average, large IT projects run 45 % over budget, 7 % over schedule, and deliver 56 % less value than predicted, per the joint McKinsey and University of Oxford BT Centre study of 5,400 IT projects.
• Only 31 % of software projects are successful on time, on scope, and on budget, according to the Standish Group CHAOS 2020 data set.
• 45 % of all projects experience scope creep, with unclear goals (64 %) and inadequate planning (57 %) cited as the top causes by the Project Management Institute.
• The Cone of Uncertainty (Steve McConnell, 2006) shows initial-concept estimates can be wrong by a factor of 4x in either direction, narrowing only as the definition refines.
• A genuine discovery phase costs 10 % to 15 % of total project budget and prevents the 40 % to 60 % development-cost premium that follows skipping it.

What fixed bid software project scoping actually is

A fixed bid software project is a contract under which the agency commits to deliver an agreed list of features, by an agreed date, for an agreed price. Once signed, the price does not move unless scope moves through a formal change control process. Fixed bid software project scoping is the work that produces that contract. The artefact is short. The work behind it is not.

The scoping engagement at La Boétie produces five concrete deliverables: a functional specification with acceptance criteria for every feature, a technical architecture document naming every external dependency and integration boundary, a milestone schedule with payment triggers, a risk register listing every identified unknown with mitigation cost and probability, and a signed statement of work. The statement of work (the legal document that binds the engagement) references the first four as exhibits. Anything not in those exhibits is out of scope, and out of scope is the most important phrase in the contract.

The market context makes the stakes obvious. Fixed-price contracts tend to embed a 15 % to 30 % buffer for unknowns, according to a comparative analysis published by Baytech Consulting in 2025. The client pays that buffer whether the risk materialises or not. The agency that scopes carelessly either eats the overrun or fights the client over change requests; either outcome poisons the relationship.

Fixed bid software project scoping is therefore an exercise in pricing risk. The agency that gets it right has done four things: it has refused projects that cannot be scoped, it has front-loaded the cone of uncertainty by paying for a discovery phase, it has named every assumption in the contract, and it has built a change control process (a formal mechanism for handling new requirements after contract signature) the client believes is fair.

When the model fits

Fixed bid software project scoping is the correct frame when three conditions hold. First, the problem is well-defined and stable: the reader of the spec one year from now would still recognise the brief. Second, the surface area is bounded: a marketing site, a B2B portal with a closed feature list, a regulated workflow that mirrors an existing paper process. Third, the client values budget certainty above the ability to redirect mid-flight; the CFO (chief financial officer) needs a single line on the budget, not a running meter.

A government-grade compliance portal, an e-commerce migration that mirrors the existing site, the build-out of a fixed-spec marketing platform: these scope cleanly. A consumer product searching for product-market fit does not, and no amount of workshop hours will make it so.

When the model is wrong

The most damaging fixed-bid engagements share a pattern: the client treats the contract as a way to push estimation risk onto the agency, while keeping the right to change their mind. A 2017 study published in the International Journal of Project Management found fixed-price contracts correlate with higher project failure rates than time-and-materials contracts of equivalent complexity, and the pattern repeats across every fixed bid software project scoping engagement the studio has reviewed in the field. The mechanism is mundane: every change request becomes a price negotiation, every negotiation slows delivery, every slowed sprint compounds risk on the next milestone.

When the model is wrong, the studio refuses the engagement or proposes a hybrid. Walking away from a poorly-scoped fixed bid is the most valuable advice an agency can give. Refusing the contract is faster than rescoping it once the change-request war has started.

The La Boétie house position on fixed bid software project scoping

The industry consensus on fixed bid software project scoping is built around a vendor-friendly fiction: that any project can be scoped, given enough hours, by anyone willing to write a long-enough specification. We disagree. The studio's house position is shorter and more useful.

First, fixed bid software project scoping is a senior engineering exercise, not a sales exercise. The person writing the spec must be the person who will be accountable for the build. La Boétie does not hand scoping to a business analyst then transfer the result to an unrelated build team; we cannot, because we are five to six engineers and the scoper is the builder. Agencies that separate the two functions are pricing a fiction.

Second, the discovery phase is non-negotiable and the client pays for it. A free scoping engagement is a sales pitch dressed as a deliverable; the agency cannot afford to do real work on speculation, so the deliverable is shallow by construction. We charge for discovery, scope it as its own small fixed-bid engagement, and walk away with our hours paid if the larger contract does not happen. The client gets a specification they own and can take elsewhere. That asymmetry is the sovereignty thesis applied to scoping: the artefact belongs to the buyer, not the vendor.

Third, the scope of a fixed bid is the scope, not the aspiration. We list features by acceptance criteria, not by aspirational phrasing. "Single sign-on" is not a feature; "Single sign-on against the client's existing Microsoft Entra ID tenant, supporting the OpenID Connect authorization code flow with PKCE, with logout propagation" is a feature. The longer phrasing is also harder to argue about three months in.

Fourth, the risk register is the contract's most important exhibit. Every fixed bid has unknowns. We name them, price them with a probability and an impact, and assign each one to a mitigation owner. When an unknown turns into a known, the register is the document that governs the conversation. Agencies that hide risks in a buffered price are pricing the unknown without naming it; that is how black-swan overruns happen.

Fifth, a fixed bid that uses agile delivery is a contract with two clauses. We borrow Jeff Sutherland's Money for Nothing, Change for Free construct: any new backlog item can replace an item of equivalent estimated effort at no additional cost (Change for Free), and the client may cancel the engagement at any sprint boundary by paying 20 % of the remaining contract value (Money for Nothing). Sutherland published a case where a client paid 3.2 million dollars against a 10 million dollar bid and received the working product seventeen months early because both clauses fired. Without those clauses, a fixed bid becomes a waterfall in disguise, and the scoping anti-patterns reference covers the failure modes that follow.

Where we disagree with the field, broadly, is on the framing. Generic listicle treatments of the topic (the kind dominating today's top-five results on the target query, including overviews from 10up and major consultancies) survey the surface without committing to a decision rule. We commit. The studio takes a position; the position is published; the position is reviewed against engagement data each year.

The discovery phase that earns a fixed bid

The discovery phase (the paid pre-contract work that produces the scope) is what makes a fixed bid honest. Fixed bid software project scoping without a paid discovery phase is a guess wearing a contract, and the agency is the only party gambling.

The right budget for discovery sits between 10 % and 25 % of the expected build cost, depending on complexity, per a synthesis of agency benchmarks published by 8allocate in 2023. Skipping discovery on fixed bid software project scoping does not save money; the same source reports that companies that skip discovery spend 40 % to 60 % more on development than companies that invest 5 % to 10 % up front. Discovery costs money. Not doing it costs more.

The La Boétie scoping ritual runs in five passes, each producing a named artefact. We document the full step-by-step in the scoping walkthrough reference; the summary below names the passes so you can plan the calendar.

1. Intent capture. A two-hour interview with the executive sponsor produces a one-page brief: business outcome, hard constraints, decision authority, end date that matters and why. The brief is signed before the next pass starts. If the executive sponsor cannot make this meeting, the engagement is not ready to scope.
2. Functional decomposition. A one-week pass through every user-facing feature, written as acceptance criteria. Each criterion takes the shape "given X, when Y, then Z". We refuse criteria that contain the word "intuitive" or "seamless"; those words are arguments, not specs.
3. Technical architecture. A two-day deep dive on every integration boundary: authentication, payment, email, search, observability, data residency. Each external dependency gets a row in the dependencies register with its uptime guarantee, its versioning policy, and its termination clause. Vendor lock-in (a contract structure that makes leaving a supplier expensive) is named here or it becomes a surprise later.
4. Risk register. One day of structured threat modelling against the architecture: what could change between signature and delivery (regulatory shift, dependency deprecation, key personnel departure, performance budget) and what each shift would cost. Each risk gets a probability band, an impact range, and a mitigation owner.
5. Pricing and proposal. Three-point estimates for every feature using the PERT formula (O + 4M + P) / 6, where O is optimistic, M is most likely, and P is pessimistic. The published price uses the weighted mean plus a one-sigma buffer; the buffer is itemised on the risk register, not hidden in a round number.

The artefact set at the end of discovery is the same set we list above for the contract: spec, architecture, milestones, risk register, statement of work. The client either signs and starts the build, or pays the discovery invoice and walks away with documents they own. Either outcome is fine. The sovereignty thesis demands the latter remain a real option.

What competent discovery actually finds

Three categories of finding repay the discovery investment by an order of magnitude. The first is buried constraints: a regulator the executive sponsor forgot to mention, a data residency requirement, a parent-company procurement rule that bans certain stacks. The second is integration debt: an existing system the new product must talk to that has no documented API, a vendor portal that requires a partnership agreement, an authentication source that only speaks SAML 1.1. The third is organisational asymmetry: the person who will sign the contract is not the person who will use the product, and their objectives diverge.

All three categories surface predictably during the architecture and risk passes. Agencies that skip those passes meet the constraints in week six of the build, when they are five times more expensive to handle.

Decision rule: fixed bid versus the alternatives

The studio applies a one-page decision rule for fixed bid software project scoping before quoting any engagement. We publish it in full as the scoping detail decision framework reference; the table below is the rule's headline view, comparing the three engagement models we actually use.

The rule itself is shorter than the table. If the scope is bounded and stable, fixed bid. If the scope is exploratory and the client values learning over budget certainty, time and materials. If the direction is clear but the detail is uncertain, hybrid. The studio refuses the configuration where the scope is exploratory but the client demands a fixed price, because that configuration is the one with the highest catastrophic-overrun rate in the McKinsey-Oxford data: black swans, defined as overruns greater than 200 %, occur in 17 % of large IT projects, and almost all of them shared this contract shape.

When the configuration is borderline, we score it on the fixed bid versus value-based pricing side-by-side reference, which scores the engagement against eleven dimensions and produces a recommendation. Eight or more dimensions favouring fixed bid means fixed bid. Below that, we propose the hybrid or refuse the engagement.

Why we refuse and what to do then

The studio refuses about one in four fixed-bid requests. The refusals fall in two patterns: the client cannot or will not commit to discovery, or the scope is exploratory dressed in feature-list clothing. Both refusals come with a recommendation. The first becomes a discovery-only engagement: pay for the spec, take it elsewhere if you wish. The second becomes a time-and-materials sprint zero: build the riskiest two features first, then rescope from data.

The industry incentive structure pushes agencies to accept these engagements anyway and bill change requests later. We do not. Pushed-through fixed bids damage the relationship and the brand. The opportunity cost of saying no once is recovered three engagements later, when the same client returns with a better-formed brief.

Three engagements where the playbook was load-bearing

Three La Boétie engagements illustrate fixed bid software project scoping in practice. Names are masked because client confidentiality persists past delivery; the engagement shapes are public.

A regulated finance platform, France, 7 month build, 320 k euro contract. The scope was a multi-tenant subscription workflow with a regulated KYC integration. Discovery surfaced that the chosen KYC provider's API had been deprecated three months before contract signature; the client had budgeted using the old provider's pricing. We rescoped before signing, switched the integration to a maintained vendor, and the build delivered on schedule. The risk register had named API deprecation as a probable risk; without that line, the engagement would have shipped six weeks late. The full teardown lives in the SaaS migration scoping case study reference.

An auction platform replatform, France, 5 month build, 180 k euro contract. The legacy site ran on a bespoke PHP codebase; the executive sponsor framed the project as a like-for-like rebuild. Discovery's intent-capture interview revealed the actual business outcome was a 40 % reduction in support tickets per closed auction. We rewrote the spec to optimise for that metric, dropped two features the sponsor had assumed were necessary, and delivered the rebuild four weeks early at the original price. The metric improved by 47 % in the first quarter post-launch. Without the intent-capture pass, the build would have shipped a thicker version of the same support problem.

A legal services portal, France, 4 month build, 140 k euro contract. The discovery phase found a buried constraint: the bar association required logs of every document access by client, with a five-year retention window. The original architecture had no audit trail; surfacing this in discovery moved the work into the contract at signature, where it cost 12 k euros to design in. Finding the same requirement in week six of the build would have cost an estimated 45 k euros to retrofit. The constraint had been there the whole time; the executive sponsor simply did not know to mention it. That is the discovery phase doing its job. The post-mortem for a sister engagement where this finding did not happen in time is documented in the underscoped project postmortem reference.

Three fixed bid software project scoping engagements, three findings, three preserved margins. None of them are visible to a buyer reading a generic listicle on fixed bid contracts. All of them are visible to a buyer reading a published scoping process.

What is changing in fixed-bid scoping in 2026

Three shifts are reshaping fixed bid software project scoping, and the studio has adjusted its posture for each.

The first shift is AI-assisted fixed bid software project scoping. Founders increasingly arrive having spent a month with Lovable, Bolt, or Claude Code, producing a working prototype with no auth, no observability, and an exposed environment file. The prototype is a useful spec artefact: it shows intent. It is a dangerous artefact when treated as a starting codebase: the agency that quotes a fixed bid against an insecure prototype is pricing rework as new work. The studio now uses these prototypes as discovery inputs, not as architectural baselines. We measure how much can be salvaged, name the rebuild cost honestly, and price accordingly. The benchmark data behind this adjustment is documented in the scoping accuracy benchmarks reference.

The second shift is European digital sovereignty pressure. Clients exiting US hyperscalers (the named pattern across our 2025 pipeline) want fixed bids that include a documented exit path from each cloud, payment, and observability vendor. We now embed a sovereignty exhibit in every contract: every vendor named in the architecture must have a documented replacement path, with the estimated cost to switch noted at signature. This adds three to five days to discovery and saves the client from a six-figure migration argument later. The European scoping field report reference captures the patterns we see from clients leaving AWS, Vercel, and Twilio for European-controlled alternatives.

The third shift is regulator-driven scope inflation. AI Act enforcement timelines, NIS2 transposition, and the DSA are adding mandatory features (logging, data lineage, accessibility) to projects that did not need them in 2024. Discovery now includes a one-day regulatory pass against the client's sector. The cost of that pass is rounding error against the cost of a post-launch enforcement action.

None of these shifts changes the fundamentals of fixed bid software project scoping. All of them change what a competent fixed bid software project scoping discovery phase produces. The studio updates its scoping checklist on a six-month cycle; the next revision lands in September 2026.

How to read this hub by your starting condition

This pillar maps fixed bid software project scoping at the hub level. The siblings are the streets. Read them in this order depending on where you are starting.

1. You are about to sign a fixed-bid contract somebody else wrote. Read the client due diligence on scope reference first. It is the buyer-side checklist for reviewing a vendor's scope before signature. Read the scoping anti-patterns reference second. If the vendor's scope matches three or more anti-patterns, do not sign.
2. You are choosing between fixed bid and time and materials for a new project. Read the fixed bid versus value-based pricing comparison first, then the decision framework. Score your project on both. If the two agree, follow the answer. If they disagree, treat the discrepancy as a discovery finding and pay an agency to resolve it.
3. You are an agency learning to scope better. Read the scoping walkthrough first for the studio's working process, then the underscoped project postmortem for what to avoid, then the scoping accuracy benchmarks reference for the numbers your bids should be measured against.
4. You are pricing your first ever fixed bid. Read the discovery section above three times. Then read the scoping walkthrough. Resist the temptation to skip discovery for a small-feeling project; small-feeling projects produce most of the catastrophic overruns the studio sees.
5. You are mid-build and watching a fixed bid go sideways. Read the underscoped project postmortem first. If the symptoms match, the contract probably needs an honest renegotiation, not another sprint of pretending. The longer the conversation is delayed, the more expensive it becomes.

FAQ: fixed bid software project scoping

What is the difference between fixed bid software project scoping and a quote?

Fixed bid software project scoping is a paid engagement that produces a contractually binding specification, architecture, risk register, and milestone schedule. A quote is a price written on top of an undocumented understanding. The studio refuses fixed-bid engagements without scoping, because the McKinsey-Oxford data shows that undocumented scope is the single largest predictor of cost overruns, with 17 % of unscoped large projects exceeding 200 % of the original budget.

How long should a fixed bid scoping phase take?

For a project budgeted between 100 k and 400 k euros, the scoping phase typically runs two to four weeks of calendar time and consumes between 10 % and 15 % of the expected build cost. For projects above 1 million euros, the scoping phase can run six to ten weeks. Compressing scoping below these durations consistently produces black-swan overruns. The discovery phase is not negotiable scope; it is the contract that protects both sides.

Can a fixed bid use agile delivery?

Yes, with explicit clauses. The studio uses the Money for Nothing and Change for Free construct (Jeff Sutherland, Scrum.org). Change for Free swaps any new backlog item for an equal-effort item already in scope at no additional cost. Money for Nothing lets the client cancel at any sprint boundary for 20 % of the remaining contract value. Without those clauses, a fixed bid with agile delivery is waterfall in costume and produces the worst of both models.

Who pays for the scoping phase?

The client pays. Free scoping is a sales pitch dressed as a deliverable; the work depth is constrained by what the agency can afford to do on speculation. La Boétie quotes scoping as its own small fixed-bid engagement. If the larger build does not happen, the client takes the documents and uses them elsewhere. The artefact belongs to the buyer, not the vendor. That is the sovereignty thesis applied to scoping.

What happens when scope changes after the contract is signed?

Every change goes through the change control process named in the statement of work. The process requires a written change request describing the change, the impact on cost and timeline, and the approver. Approved changes are appended to the contract as an amendment with their own price and date. Refusing to handle changes through this process is the single most common mistake on both sides; it converts every conversation into a renegotiation and dissolves the trust the contract was supposed to encode.

How do you handle vendor lock-in inside a fixed bid?

Every external dependency in the architecture exhibit gets a row in the dependencies register, with its uptime guarantee, versioning policy, termination clause, and an estimated cost to replace. La Boétie now includes a sovereignty exhibit in every contract that names a replacement path for each named vendor. This adds three to five days to discovery and prevents the six-figure migration arguments that follow a poorly-named dependency. Étienne de La Boétie wrote in 1548 that voluntary servitude is the only servitude that lasts; vendor lock-in is its software-era equivalent.

How La Boétie handles fixed bid software project scoping

The studio runs every fixed bid software project scoping engagement through the same pipeline. We refuse engagements that fall outside our decision rule and propose alternatives when the configuration is borderline. The promise to the operator is short.

Senior scoping that doubles as the build plan. The engineer who scopes the work is the engineer who delivers it. We do not separate scoping from delivery, because separating them prices a fiction. Every contract is signed by someone who will be accountable for the code three months later. La Boétie has scoped and delivered builds for france-epargne.fr, llb-auction.com, assuied-avocat.fr, todopsy.fr, vertena.fr, and a dozen other operators across regulated industries.

A paid discovery phase the client owns. Discovery is scoped, priced, and delivered as its own engagement. The artefact set (spec, architecture, risk register, milestones, statement of work) belongs to the client at the end of discovery regardless of whether the build proceeds. The artefact is portable; the relationship is optional.

A risk register the client can read. Every unknown gets a row with a probability, an impact, and a mitigation owner. No hidden buffers. No round-number padding. The price is the price, and the assumptions behind it are visible to the buyer at signature.

A sovereignty exhibit on every contract. Every external dependency is named, every replacement path is documented, and the cost to switch is estimated up front. Vendor lock-in is a contract structure, not an accident; we treat it as a scope item the client can refuse.

If you are about to sign or scope a fixed bid software project scoping engagement and want a second pair of senior eyes before you commit, book a studio intro call. One hour, no obligation, and you keep the notes.

Conclusion

Fixed bid software project scoping is the contract conversation that decides whether the build succeeds. The discipline is simple to describe and hard to execute: refuse projects that cannot be scoped, pay for a real discovery phase, name every assumption in writing, build a change control process the client believes is fair, and treat vendor lock-in as a contract clause the buyer can edit. The agencies that do these five things publish their decision rules; the agencies that do not, hide behind generic listicles. La Boétie publishes. If you read one article from this hub before you sign anything, this is the one; read the focal pieces next for the depth your engagement actually needs, and treat fixed bid software project scoping as the leverage point it is.

À lire également :

• Scoping walkthrough reference
• Scoping accuracy benchmarks reference
• European scoping field report reference
• Scoping detail decision framework reference
• Client due diligence on scope reference
• Fixed bid versus value-based pricing side-by-side reference
• SaaS migration scoping case study reference
• Underscoped project postmortem reference
• Scoping anti-patterns reference
• Scoping effort cost breakdown reference

Sources :

• Delivering large-scale IT projects on time, on budget, and on value : McKinsey and University of Oxford BT Centre for Major Programme Management, 2012
• CHAOS Report: Decision Latency Theory : The Standish Group, 2020
• Software Estimation: Demystifying the Black Art : Steve McConnell, Microsoft Press, 2006
• Pulse of the Profession 2024: The Future of Project Work : Project Management Institute, 2024
• Top Five Causes of Scope Creep : Project Management Institute, 2013
• Can You Be Agile With Fixed Bid Projects? (Money for Nothing, Change for Free) : Scrum.org, Jeff Sutherland framework
• Time and Materials vs Fixed Price: Which Delivers Better ROI? : Baytech Consulting, 2025
• Why You Should Spend Up to 10% of Project Time on Discovery : 8allocate, 2023
• 10up agency overview : 10up, referenced as the field's distributed-WordPress agency