The dominant factor is rarely technology — it is almost always unclear scope. Each unanswered question in the specification turns into padding inside the number you receive. A supplier that cannot see the exceptions and edge cases will assume a pessimistic case. Investing a few days in requirements work often reduces the total far more than haggling over hourly rates.

Connections to other systems are the next major multiplier. A screen that writes to your own database is easy to estimate; the same functionality talking to a payment provider and a CRM is another matter entirely. The effort lives in the counterparty: rate limits and sandbox access, slow approval cycles, data that does not match your model. Ask any vendor to break integrations out as separate items, because that is where the numbers slip.

The requirements nobody writes down silently change the number. An internal tool used by a small internal team is a very different build from the same feature set handling public traffic. Compliance work, high availability, .net core cross-platform development scalability, traceability and localisation add weeks of work. State them early or expect them priced as extras.

The team you are quoted matters. A rate card tells you almost nothing on its own: one senior developer at twice the price is often cheaper overall than two juniors who need supervision and rework. Ask as well which roles are billed: project management, testing, infrastructure work and design are real work, but they should be named rather than hidden inside a blended rate.

The build price is not what you will actually spend. Plan for hosting, smm agency subscriptions and licences, logging and alerting and a maintenance allowance annually. A useful planning figure says that a live system consumes a recurring percentage of its original build cost per year for updates, security patches and small improvements. Ignoring this remains the most frequent planning error.