The biggest cost driver is never technology — it is almost always unclear scope. Every open question in the requirements is converted into a contingency inside the number you receive. A vendor that cannot see what happens on the unhappy path has to assume a pessimistic case. Putting two weeks into a discovery phase frequently cuts the total far more than negotiating the rate.
Integrations are another reliable source of cost. A feature that touches only your own data is predictable; the same screen talking to a payment provider and a CRM is a different problem. The cost sits in the third party: poor documentation, slow approval cycles, data that does not match your model. Ask the estimator to price integrations separately, since this is where estimates break.
Quality attributes silently change the budget. An application used by a small internal team costs far less than the same functionality serving thousands of external customers. Security reviews, availability guarantees, load handling, traceability and localisation each add weeks of work. Write them down at the start or you can expect them to arrive later as change requests.
The team you are quoted matters. A day rate says little on its own: an experienced engineer at a higher rate can be less expensive in the end than two inexperienced hire dedicated developers who require supervision and rework. Also ask who else is billed: delivery management, quality assurance, DevOps and UX design are real work, but they should be named rather than hidden inside a blended rate.
The quoted figure is never the total cost. Plan for infrastructure, third-party licences, logging and alerting and a change budget each year. A useful planning figure is that custom software vs saas in active use needs a meaningful share of its original build cost per year simply to stay current. Treating the launch as the finish line is the most frequent planning error.