The dominant factor is not technology — it remains unclear scope. Each unanswered question in the specification becomes a buffer somewhere in the quote. A vendor that does not know the edge cases must assume the more expensive option. Putting two weeks into a proper discovery frequently cuts the overall figure far more than negotiating the rate.

Integrations tend to be another reliable source of cost. A feature that touches only your own data is predictable; the same screen talking to a legacy ERP is another matter entirely. The effort lives in the other system: poor documentation, waiting on someone else's team, inconsistent data. Ask each bidder to price integrations separately, since that is where the numbers slip.

Quality attributes quietly rewrite the number. An internal tool used by twenty people has almost nothing in common with the same functionality serving public traffic. Audit and compliance requirements, hire node expert high availability, load handling, audit logging and localisation all add weeks of work. State them early or you can expect the estimate to move later.

The mix of people behind the number matters. A rate card says very little on its own: one senior developer at a premium rate frequently turns out to be cheaper per delivered feature than two juniors who require supervision and rework. Also ask which roles are billed: delivery management, QA, infrastructure work and UX design are real work, but these should be visible in the estimate.

The quoted figure is rarely the total cost. Expect infrastructure, third-party licences, hire webassembly developers logging and alerting and a maintenance allowance for every year the software runs. A common working assumption is that a live system requires a recurring percentage of the initial investment every year for updates, security patches and small improvements. Leaving it out of the budget remains the most common budgeting mistake.