The dominant factor is never technology — it is almost always unclear scope. Every ambiguity in the specification becomes padding in the estimate. A vendor that cannot see the edge cases has to assume a pessimistic case. Putting two weeks into requirements work often reduces the final cost much more than negotiating the rate.

Integrations remain the second big multiplier. A screen that writes to your own database is low risk; the same functionality talking to a legacy ERP is a different problem. The cost sits in the other system: poor documentation, waiting on someone else's team, fields that mean something different on each side. Ask the estimator to list every external system, because that is where the numbers slip.

Non-functional requirements can easily double the budget. A tool used by a handful of staff costs far less than the same functionality serving thousands of external customers. Compliance work, availability guarantees, performance under load, data retention rules and localisation all add real engineering time. State them early or you can expect them to arrive later as change requests.

The mix of people behind the number changes the arithmetic. A day rate says little on its own: a senior engineer at twice the price frequently turns out to be cheaper overall than two juniors who need heavy code review. Ask as well what else appears on the invoice: delivery management, quality assurance, release engineering and analysis are real work, but these should be visible in the estimate.

The build price is rarely the full cost of ownership. Expect infrastructure, subscriptions and licences, monitoring and a change budget each year. A common working assumption is that edtech software development in active use consumes a recurring percentage of its original build cost every year for updates, startup mvp development security patches and offshore software development small improvements. Ignoring this remains the most frequent planning error.