How to Tell If a Software Agency Is Padding the Scope (and the Questions That Expose It)

If you want to know how to tell if a software agency is padding the scope, read the quote for what it will not show you. Padding hides in a lump sum with no line items, in a contingency nobody explains, in a team heavier than the work, and in a rebuild proposed before anyone has read your code. This guide gives you the signs, the question that exposes each, and what an honest quote looks like, including when the big number is the honest one.

I run Razoyo, a software engineering firm in The Colony, Texas, that has taken prototypes and constrained systems into production since 2011. We write quotes for a living, so every test below works on ours too. Use them on us.

How do I know if a software agency is padding the scope?

A quote is padded when you cannot trace the total back to specific pieces of work, each with its own effort and price. Padding is not always dishonest. Usually it is a vendor covering risk it has not understood, and you pay for it either way. Our own scoping page says it plainly: “A vendor who has not scoped either pads or lowballs.”

Six signs, roughly in the order they show up:

• One lump sum, no line items. “Platform build: $180,000” gives you nothing to check.
• Deliverables written as activities. “Development and testing as needed” describes time passing, not software.
• A contingency with no basis. A risk reserve is legitimate. One with no named risks and no rule for who approves spending it is margin with a polite name.
• A rebuild proposed before anyone read the code. If the first call ends in “we would start fresh,” ask what they looked at. Often it was a demo and a conversation.
• A team heavier than the work. A small internal tool staffed with a full-time project manager, an architect, a QA lead and three developers is a staffing plan looking for a project.
• No place to stop. One signature for the whole build, with nothing you own until the end, puts all of the vendor’s estimating risk on you.

The opposite failure costs just as much. As that same page puts it, lowballing “wins the deal and finds the real scope later,” through change orders.

What questions expose each sign?

The questions that expose padding all ask the vendor to show their work: what they read, what each piece costs, and what happens when an assumption breaks. An honest vendor can answer every row in the meeting.

How do I tell if an agency is proposing a rebuild I do not need?

A rebuild recommendation is only credible if the firm can tell you what it read and which finding forced it. “The code is messy” is not a finding. Messy code on a sound structure can usually be repaired. What forces a rebuild is a foundation that cannot carry where the product has to go.

Ask for the evidence by dimension. When we do technical due diligence, we check the same seven things every time: security and access, data integrity, architecture, test coverage, observability and alerting, a real deploy path, and documented ownership. A real rebuild case points at the expensive dimensions, usually the data model and the architecture. Missing tests and a manual deploy are cheap to fix.

Then ask the question that reveals the incentive: “What would the cheaper path cost, and why did you reject it?” A firm that never priced the repair has done a sales call, not an assessment. Our guide to rewrite versus refactor on an inherited codebase walks through that decision.

Here is what an honest rebuild looks like. Matrix began as an internal CRM for hotel sales teams, built for a single organization: every data model and workflow was scoped to one tenant, and performance was unreliable. To become a product many hotel groups could use, the foundation had to change, so we rebuilt it as Matrix, a multi-tenant SaaS platform, for M1 Intel. The case fit in one checkable sentence: it was single-tenant to its core. Hold every rebuild proposal to that standard.

Why do custom software projects go over budget?

Custom software projects go over budget mainly because the work was never defined well enough to price, and because software overruns are lopsided: most projects miss by a little, and a meaningful minority miss by multiples. The research agrees on the shape.

• McKinsey and Oxford. In research with the University of Oxford on more than 5,400 IT projects, McKinsey found that large IT projects, those starting above $15 million, ran on average 45 percent over budget and 7 percent over time while delivering 56 percent less value than predicted. Software projects carried the highest overrun risk.
• The fat tail. Bent Flyvbjerg and Alexander Budzier studied 1,471 IT projects and found an average cost overrun of 27 percent. One in six was a “black swan,” with an average cost overrun of 200 percent and a schedule overrun of almost 70 percent.

Be fair about the limits: the Flyvbjerg projects averaged $167 million and drew heavily on public agencies, and a $40,000 build is not an ERP rollout. But the shape transfers, and so does their advice: break big projects into pieces of limited size, complexity and duration. We left out the Standish CHAOS figures common on this topic because we could not check them against the original report.

From our side of the table, the cause is rarely the code. As our scoping page puts it, the reason projects overrun “is almost never a surprise in the code.” It is that nobody agreed what a piece of work was worth before it started. Vague requirements let “the build” mean three different systems depending on who you ask.

So a vendor facing an undefined scope can pad the quote to survive the tail, or define the scope until the tail shrinks. Only the second is worth paying for.

Fixed price or time and materials: which protects you?

Neither protects you on its own: fixed price moves the overrun risk to the vendor, who prices it in, and time and materials keeps the risk with you, which only works with a ceiling and an approval on each piece. US federal contracting rules say it plainly. A firm-fixed-price contract, per FAR 16.202-1, places “maximum risk” on the contractor. That is why a fixed bid on an undefined scope carries padding: the vendor is buying insurance against your unknowns, with your money. Time and materials, per FAR 16.601, fits only when the extent or duration of the work cannot be estimated accurately up front, gives the contractor no profit incentive to control cost, and needs a ceiling price and real oversight.

The third row is how Razoyo works, so weigh my opinion accordingly. The System Spec is $2,500 fixed because it is bounded work. The build carries a range until the Spec exists, then gets a real number in writing, and a business analyst puts a level of effort and a budget on each piece of work and gets your confirmation first. The full ladder is on our process page.

What does an honest software quote look like?

An honest software quote shows its work: what it is based on, what each piece costs, what it assumes, and where you can stop.

• A written basis. It names the spec or requirements package it prices. A build price before the product is defined is, in the words of our pricing page, “a guess dressed up as a number.”
• Line items with effort. Each piece carries an estimate in days or hours and a price, and the pieces add up to the total.
• Named assumptions. The few things that, if wrong, move the number.
• A visible contingency. Sized, tied to named risks, drawn only with your approval.
• Stopping points. After each phase you own something usable.
• Approval before spend. No piece of work starts until you confirm its estimate.

Stopping points matter. When a vacation-rental startup asked us to build a two-sided marketplace, we did not quote the build. We ran a $2,500 fixed-fee Production Spec instead. The product brief arrived ten days after kickoff, the PRD two weeks after that, and a working prototype of the host side within six weeks. The most they ever had at risk was $2,500.

When is a big quote the honest one?

A big quote is honest when it is big for reasons you can see: a foundation that has to change, integrations with systems you do not control, data that must move without loss, compliance work, or real scale. Matrix was one. The test is whether every part of the number traces to something in your project.

Sometimes the honest number is bigger than you hoped. Our scoping page describes a Spec where the estimate came back larger than the founder had in mind, and we did not shave it to make it easier to sign. She took the finished Spec to a development partner who could fund the build. A quote shaved to fit your budget is padding in reverse: the missing money comes back as change orders.

And sometimes you do not need a firm like ours. If your project is genuinely simple and already well defined, a freelancer may be the right call, and our pricing page says so. For something already built, our comparison of firms that take over existing codebases names alternatives and where each beats us.

What should I ask a software development agency before signing?

Before signing, ask questions that make the vendor commit in writing to what they read, what each piece costs, and what you keep if you stop. Beyond the table above:

• “What did you read before giving me this number?” A demo and a call is not enough.
• “What happens when you find something you did not expect?” The right answer is a new estimate, your approval, then work. The wrong answer is an invoice.
• “Will you ever tell me not to build this?” Our Spec is fixed price whether the answer is build or don’t, so we gain nothing by inflating it.
• “Who owns the code, in writing?” Our wording: once fees are paid you own the code we write for you.

For what each step actually costs, see what it costs to take an AI-built prototype to production.

Razoyo’s Six-Line Quote Check

Run any quote through these six lines, ours included. Each is pass or fail, and each comes from how we price our own work.

1. Basis. The quote names the written spec it prices. Fail if it prices a conversation.
2. Pieces. Every piece of work has its own level of effort and budget, and the pieces add up to the total. Fail if the only number is the total.
3. Reserve. Any contingency is sized, tied to named risks, and drawn only with your approval. Fail if it is a bare percentage.
4. Evidence. Any rebuild recommendation cites findings from reading the code, by dimension, and prices the cheaper path it rejected.
5. Exit. You can stop after the first paid step and keep what you paid for. Ours is a $2,500 fixed System Spec, and the product brief and PRD are yours whether or not you build with us.
6. Approval. No work starts without your sign-off on its estimate. Ours fits in four words on our pricing page: “No approval, no work.”

Six passes means you are comparing on price and fit. Four or five means ask for the missing lines in writing. Three or fewer means nobody has scoped the work, and you would be paying for the guess.

So what should you do with the quote on your desk?

Run it through the six lines before you negotiate the price, because a padded number negotiated down is still an unscoped project. If it fails on basis and pieces, scope the work first, then ask every vendor to price the same document. That is the only way two quotes become comparable.

Key takeaways

• Padding hides where you cannot see. A total you cannot trace to priced pieces of work is the first sign.
• Lowballing is the same problem later. A vague low quote finds the real scope through change orders.
• A rebuild needs a reason you can check. Ask what they read and what the cheaper path would cost.
• Overruns are lopsided. Most projects miss a little and some miss by multiples, so buy in small, bounded steps.
• Both contract models need structure. Fixed price needs a written scope; time and materials needs a ceiling and per-piece approval.
• A big quote can be honest. It is honest when every part traces to something real in your project.

Key terms glossary

• Scope padding. Cost in a quote that does not trace to defined work, usually covering risk the vendor has not assessed.
• Lowballing. Quoting below the real cost to win the deal, then recovering the gap through change orders.
• Line item. One defined piece of work in a quote, with its own estimate and price.
• Contingency. A reserve for named risks, sized, explained and drawn only with the buyer’s approval.
• Fixed price. A contract whose price does not move with the vendor’s actual costs, so the vendor carries the overrun risk.
• Time and materials. A contract billed on hours worked plus costs, so the buyer carries the overrun risk.
• Ceiling price. A cap on a time and materials contract that the vendor exceeds at its own risk.
• System Spec. Razoyo’s $2,500 fixed first paid step: a product brief, a PRD and a real build estimate, time-boxed.

FAQ

How do I know if a software quote is padded? Ask the vendor to break the total into pieces of work, each with its own effort estimate and price. If they cannot, or the pieces do not add up to the total, the number is covering risk nobody has assessed.

Is a contingency in a software quote a red flag? Not by itself. A contingency is legitimate when it is sized, tied to named risks, and drawn only with your approval. It becomes a red flag when it is a flat percentage with no reasons and no rule for who decides to spend it.

How do I know if I really need a rebuild? A rebuild is justified when the foundation cannot carry where the product has to go, usually the data model or the architecture. Messy code on a sound structure can usually be repaired while the product keeps running. Ask what the firm read, which finding forced the recommendation, and what the cheaper repair would cost.

Why do custom software projects go over budget? Mostly because the work was never defined well enough to price. McKinsey and the University of Oxford found large IT projects ran 45 percent over budget on average, and Flyvbjerg and Budzier found one in six IT projects overran cost by 200 percent on average. Buying in small, bounded steps limits that exposure.

Is fixed price or time and materials better for custom software? Neither is better on its own. Fixed price moves the overrun risk to the vendor, who prices it in, so it suits small, fully specified work. Time and materials keeps the risk with you, so it needs a ceiling and an approval on each piece of work before it starts.

What should a software development quote include? The spec or requirements document it prices, line items with effort estimates, named assumptions, a visible contingency, stopping points, and approval before spend. Without the written basis, the rest is a guess.

What should I ask a software agency before signing? Ask what they read before giving you a number, what happens when they find something unexpected, whether they will ever tell you not to build, and who owns the code in writing. Vendors who have scoped the work answer these without hesitation.

How much does it cost to get a real estimate? At Razoyo, the 30 minute consultation is free and the System Spec is $2,500 fixed. The Spec produces a product brief, a PRD and a senior-engineer build estimate, and the brief and PRD are yours whether or not you build with us.

Talk it through

If you have a quote on your desk and cannot tell what is inside it, bring it to a free 30 minute consultation and we will run the Six-Line Quote Check on it with you. If it passes, you will hear that you should sign it. If the work has not been scoped yet, the next step is a $2,500 fixed System Spec that ends in a real build estimate in writing, which you can take to any team. Schedule Free Consultation.

Paul Byrne is President of Razoyo, a software engineering firm in The Colony, Texas taking prototypes and constrained systems into production since 2011.