The single largest cost driver is never the technology stack — it is almost always unclear scope. Each unanswered question in the requirements becomes a contingency inside the number you receive. A vendor that has no visibility into the edge cases will assume a pessimistic case. Investing a few days in requirements work frequently cuts the overall figure far more than any rate negotiation.

Third-party integrations remain the second big multiplier. A feature that touches only your own data is easy to estimate; the same screen connected to a payment provider and a CRM is not. The effort hides in the counterparty: undocumented APIs, slow approval cycles, inconsistent data. Ask the estimator to list every external system, since that is where the numbers slip.

Quality attributes silently change the budget. An internal tool used by a small internal team is a very different build from the same functionality serving thousands of external customers. Security reviews, availability guarantees, scalability, traceability and accessibility all add measurable effort. State them early or else expect them to arrive later as change requests.

The mix of people behind the number matters. A day rate says almost nothing on its own: an experienced engineer at twice the price frequently turns out to be cheaper per delivered feature than a pair of junior hire pytest developers who require constant review. Check too which roles are billed: project management, QA, infrastructure work and analysis have to be done by someone, but they should be itemised.

The number in the proposal is never the full cost of ownership. Budget for infrastructure, paid APIs, monitoring and an ongoing support budget annually. A common working assumption says that software in active use needs a noticeable fraction of its original build cost annually simply to stay current. Treating the launch cto as a service the finish line is the classic mistake.