How do I know if a development quote is padded

A padded quote is rarely dishonest. It is priced by time, so it earns more when the work takes longer. Look for discovery sold separately, custom builds of things you can buy, and a scope that grows the further you read. Ask what happens if it takes half as long.

You are looking at a quote. Six figures, or close to it. Twelve weeks of discovery, then a build phase with a number attached, then something called stabilisation. Every line item sounds reasonable. You have no way to tell whether any of it is necessary, because if you could tell, you would not need to hire anyone.

So you do what everyone does. You get a second quote. It comes back at half the price with half the words, and now you are worse off than before, because one of them is wrong and you still cannot tell which.

What I would want to know in your position, and what almost nobody says out loud, is that most padding is not dishonest. It is structural.

Why the incentive runs the wrong way

Most of the people you would hire make more money the longer the work takes and the more complicated it gets. That is not a conspiracy. It is how the work is priced.

An agency that quotes a three month program with fifty workshops earns more than one that does the actual thing you need in a week. Both can be run by good people who sleep fine.

I ran a consulting business for years and watched this from the inside. We got good at it. Good enough that we would spot the five minute fix a client actually needed and do that instead of the drawn out program. Happy clients. No money. In a service business, efficiency is a bug.

That is the whole problem in one line. The machine you are plugging your idea into is tuned to make things bigger, slower and more custom than they need to be, and you, on the outside, reading a list of features you do not understand, have no way to separate necessary complexity from the kind that is running up the meter.

The five things I look for

None of these are proof on their own. Two or more together and I would ask hard questions.

The discovery one is worth sitting on. Discovery is real work and I charge for it. But you should finish it holding something specific: a definition of done, a fixed price, a date, and enough written detail that a completely different team could build from it. If what you get at the end of discovery is a recommendation to proceed to the build phase, you did not buy discovery. You bought a sales process.

The question that does the work

There is one question that cuts through most of it.

"What happens if this takes half as long as you think?"

Watch what happens. If the answer is that you pay less, the incentives are pointed at you. If the answer is a long pause, or a reframe about how these things always take longer, or a gentle explanation of why that is unlikely, you have learned what you needed to know.

Second question, nearly as good. "Which parts of this are you buying rather than building, and why not more?" Anyone good will have an answer immediately, because they have already made those calls and they are proud of them. The correct shape of the answer is that most of the system is proven tools somebody else maintains, and a smaller slice is the thing that is actually yours.

In our builds that split lands around thirty percent unique, seventy percent bought. Not a rule of physics, just what falls out when you keep asking whether you really need to write this bit.

The trap that is not about money

The more expensive mistake is not overpaying. It is over-building.

I trained as a data scientist. The hard maths, the interesting problems, so I can tell you exactly how a technical person thinks, because I am one. Give a data scientist the choice between a ninety nine percent solution that takes two years and might not work, and a ninety five percent solution that ships in two days, and they will take the ninety nine every time. Not out of laziness. They are trained to. Scores, not business.

Almost nobody stops to ask whether the last four percent is worth two years, or whether the ninety five was already enough to change your life. It usually was. People wildly underestimate the ninety five.

We built a scorecard product for a former university chief operating officer who knew her sector completely. The first version got engineered past the point of usefulness because the problem was genuinely interesting. The interesting version was not the useful version. That one is on us, not on her.

And once, on a build for a sports client, we spent real time on pose recognition from video before concluding the accuracy on the fringe cases would never be good enough to trust. We killed it. Telling a client that is a bad afternoon. It was still cheaper than the alternative, which was shipping something that was wrong sometimes and letting them find out.

What a quote should let you do

Read the quote again and ask whether it lets you stop.

The version I think is fair looks like this. One fixed price. Billed in sixths, one sixth as each stage completes. You can walk at any gate, pay nothing further, and keep everything produced up to that point. The repository, the infrastructure and every account are in your name from day one.

That structure is not generous. It is just the incentives pointed the same way as yours, written down. If the work stalls, I stop earning. If it goes faster than I thought, you keep the difference.

You will not get that from everyone, and there are real reasons a team might not offer it. But it is worth knowing it exists, because it changes what you are allowed to ask for.

The uncomfortable bit

Sometimes the expensive quote is correct.

Enterprise is genuinely different. Legacy integrations, security review, compliance tracks, five stakeholders who each need something slightly different. A product that has to run inside an organisation of ten thousand people is not the same animal as a product with one customer type, and pretending otherwise is how you end up with something that works in the demo and dies in procurement.

I do not have a clean rule for telling those apart from the outside. The honest test is whether the person quoting can explain which parts are expensive because of your environment and which parts are expensive because of their approach. If they can draw that line confidently, in specifics, they have probably done this before.

If they cannot, the number is a guess with a suit on.

Common questions

Is a fixed price always better than time and materials

No. Fixed price on a badly defined scope just moves the risk onto whoever wrote the definition, and they will price that risk in. A fixed price is only meaningful if the thing being priced is described tightly enough that you could hand it to a different team and get the same result.

How much of a build should be custom

In our work, roughly thirty percent. The rest should be proven tools you did not write. If a quote is mostly custom, ask which parts and why, because every custom component is something someone has to maintain forever.

What is a fair rate for a senior developer

The rate is the wrong question. Two people at the same rate can differ by a factor of five in how long they take, so the rate tells you almost nothing about the cost. Ask what you get and by when, and what happens if that date slips.