The dominant factor is rarely the technology stack — it is how much is still undecided. Every ambiguity in the brief is converted into a buffer inside the number you receive. A supplier that does not know what happens on the unhappy path must assume the more expensive option. Investing a few days in a proper discovery frequently cuts the total much more than any rate negotiation.
Third-party integrations remain the second big multiplier. A form that saves data is easy to estimate; the same functionality connected to an old accounting system is another matter entirely. The effort sits in the counterparty: rate limits and sandbox access, slow approval cycles, inconsistent data. Ask the estimator to break integrations out as separate items, hire edtech developers as this is where estimates break.
Non-functional requirements quietly rewrite the number. A tool used by a small internal team is a very different build from the same functionality handling public traffic. Compliance work, high availability, scalability, audit logging and multi-language support each add weeks of work. State them early or expect them to arrive later as change requests.
The team you are quoted changes the arithmetic. A day rate says little on its own: one senior developer at twice the price can be less expensive in the end than a pair of junior developers who need heavy code review. Check too what else appears on the invoice: project management, testing, release engineering and design are legitimate costs, but these should be itemised.
The quoted figure is never what you will actually spend. Budget for infrastructure, subscriptions and licences, monitoring and a change budget for every year the software runs. A useful planning figure holds that software in active use needs a recurring percentage of the initial investment every year in fixes, updates time and materials contract small changes. Treating the launch as the finish line remains the classic mistake.
