The single largest cost driver is never technology — it is almost always uncertainty. Every open question in the requirements turns into padding somewhere in the quote. A supplier that has no visibility into the edge cases will assume the more expensive option. Putting two weeks into a discovery phase often reduces the overall figure much more than negotiating the rate.
Third-party integrations are the next major public sector web development multiplier. A form that saves data is predictable; the same functionality talking to an old accounting system is not. The cost hides in the third party: poor documentation, waiting on someone else’s team, fixed price contract software development fields that mean something different on each side. Ask the estimator to break integrations out as separate items, because this is where estimates break.
Non-functional requirements quietly rewrite the estimate. An application used by a small internal team costs far less than the same functionality serving thousands of external customers. Compliance work, high availability, scalability, traceability and multi-language support each add real engineering time. Write them down at the start or expect the estimate to move later.
The team you are quoted matters a great deal. A day rate says almost nothing on its own: which is better laravel or .net one senior developer at a higher rate can be less expensive in the end than two inexperienced developers who need heavy code review. Also ask what else appears on the invoice: delivery management, quality assurance, infrastructure work and UX design have to be done by someone, but these should be visible in the estimate.
The number in the proposal is not the total cost. Expect hosting, paid APIs, logging and alerting and an ongoing support budget annually. A useful planning figure says that a live system consumes a meaningful share of the initial investment every year in fixes, updates and small changes. Treating the launch as the finish line has always been the classic mistake.