The dominant factor is not technology — it is uncertainty. Each unanswered question in the specification becomes a contingency somewhere in the quote. A supplier that does not know the edge cases will assume a pessimistic case. Putting two weeks into a discovery phase frequently cuts the total far more than haggling over hourly rates.
Connections to other systems remain the second big multiplier. A form that saves data is low risk; the same functionality talking to a legacy ERP is another matter entirely. The effort hides in the other system: undocumented APIs, 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.
Non-functional requirements silently change the budget. An application used by a small internal team is a very different build from the same idea serving thousands of external customers. Compliance work, uptime targets, scalability, audit logging and accessibility all add measurable effort. Write them down at the start livewire or alpine js else expect them to arrive later as change requests.
The mix of people behind the number matters. A day rate tells you very little on its own: an experienced hire grpc engineer at twice the price can be less expensive in the end than two inexperienced developers who require supervision and rework. Ask as well what else appears on the invoice: coordination, QA, infrastructure work and analysis are real work, but they should be itemised.
The build price is not the full cost of ownership. Expect cloud costs, subscriptions and licences, monitoring and an ongoing support budget for every year the software runs. A common mvp mistakes working assumption says that any production system consumes a noticeable fraction of its original build cost every year for updates, security patches and small improvements. Ignoring this remains the most frequent planning error.