The biggest cost driver is rarely the technology stack — it remains unclear scope. Every open question in the requirements turns into a contingency in the estimate. A vendor that has no visibility into the edge cases will assume a pessimistic case. Putting two weeks into requirements work often reduces the final cost far more than any rate negotiation.
Connections to other systems tend to be the second big multiplier. A form that saves data is predictable; the same functionality wired into an old accounting system is not. The effort sits in the other system: poor dedicated development team documentation, slow approval cycles, data that does not match your model. Ask the estimator to list every external system, because this is the usual source of overruns.
The requirements nobody writes down quietly rewrite the estimate. A tool used by a handful of staff costs far less than the same feature set handling public traffic. Compliance work, high availability, load handling, data retention rules and multi-language support add weeks of work. State them early or you can expect them to arrive later as change requests.
Who actually does the work matters a great deal. A day rate tells you very little on its own: an experienced engineer at twice the price is often less expensive in the end than two juniors who need constant review. Ask as well what else appears on the invoice: coordination, testing, infrastructure work and design are legitimate costs, but these should be itemised.
The number in the proposal is not the total cost. Expect cloud costs, subscriptions and licences, monitoring time and materials vs fixed price contract a maintenance allowance each year. A common working assumption is that any production system requires a recurring percentage of the original budget annually for updates, security patches and small improvements. Treating the launch as the finish line has always been the classic mistake.