The single largest cost driver is never the technology stack — it remains how much is still undecided. Each unanswered question in the requirements turns into a buffer inside the number you receive. A supplier that has no visibility into what happens on the unhappy path has to assume the worst. Spending a week on requirements work often reduces the overall figure by far more than haggling over hourly rates.

Third-party integrations remain the second big multiplier. A screen that writes to your own database is low risk; the same feature talking to an old accounting system is a different problem. The effort sits in the counterparty: igaming frontend development undocumented APIs, long certification processes, data that does not match your model. Ask the estimator to list every external system, as this is the usual source of overruns.

Quality attributes silently change the number. An internal tool used by a handful of staff costs far less than the same feature set serving public traffic. Security reviews, high availability, scalability, traceability and multi-language support each add weeks of work. State them early or expect the estimate to move later.

The mix of people behind the number changes the arithmetic. An hourly rate says almost nothing on its own: an experienced engineer at a premium rate frequently turns out to be less expensive in the end than two inexperienced hire edtech developers who need heavy code review. Check too which roles are billed: coordination, quality assurance, infrastructure work and UX design are legitimate costs, but they must be named rather than hidden inside a blended rate.

The build price is never the full cost of ownership. Plan for cloud costs, subscriptions and licences, observability and a change budget for every year the software runs. A reasonable rule of thumb is that any production system consumes a meaningful share of the initial investment per year for updates, security patches and small improvements. Ignoring this is the classic mistake.