The biggest cost driver is rarely the choice of framework — it is almost always uncertainty. Every open question in the specification becomes a contingency in the estimate. A vendor that has no visibility into the edge cases has to assume a pessimistic case. Putting two weeks into requirements work can cut the total by far more than negotiating the rate.

Third-party integrations are the second big multiplier. A screen that writes to your own database is low risk; the same screen talking to an old accounting system is another matter entirely. The unknown hides in the third party: rate limits and sandbox access, waiting on someone else's dedicated development team services, vue.js vs react.js fields that mean something different on each side. Ask any vendor to break integrations out as separate items, as that is where the numbers slip.

Non-functional requirements quietly rewrite the estimate. A tool used by twenty people costs far less than the same functionality handling public traffic. Audit and compliance requirements, availability guarantees, load handling, data retention rules and multi-language support add weeks of work. Write them down at the start or you can expect them priced as extras.

The team you are quoted matters. A day rate reveals very little on its own: a senior engineer at twice the price can be cheaper overall than a pair of junior developers who need heavy code review. Ask as well what else appears on the invoice: coordination, QA, release engineering and analysis are real work, but they must be visible in the estimate.

The number in the proposal is never the full cost of ownership. Expect hosting, third-party licences, logging and alerting and an ongoing support budget each year. A useful planning figure says that software in active use consumes a noticeable fraction of the initial investment annually in fixes, updates and small changes. Treating the launch as the finish line is the classic mistake.