The dominant factor is never the technology stack — it is almost always unclear scope. Every open question in the requirements turns into padding in the estimate. A supplier that cannot see the exceptions and edge cases has to assume a pessimistic case. Putting two weeks into a discovery phase often reduces the overall figure far more than negotiating the rate.
Integrations tend to be the next major laravel vs. symfony multiplier. A screen that writes to your own database is low risk; the same screen talking to an old accounting system is a different problem. The unknown sits in the counterparty: rate limits and sandbox access, long certification processes, inconsistent data. Ask the estimator to price integrations separately, ai integration services because this is the usual source of overruns.
Non-functional requirements quietly rewrite the estimate. A tool used by twenty people has almost nothing in common with the same feature set serving a hundred thousand users. Audit and compliance requirements, high availability, performance under load, audit logging and multi-language support all add measurable effort. Put them in the brief or you can expect them priced as extras.
The team you are quoted changes the arithmetic. A rate card tells you almost nothing on its own: one senior hire dedicated mobx developer at twice the price is often less expensive in the end than two juniors who need heavy code review. Also ask who else is billed: coordination, QA, infrastructure work and design are legitimate costs, but they must be itemised.
The quoted figure is rarely what you will actually spend. Expect cloud costs, subscriptions and licences, logging and alerting and an ongoing support budget annually. A common working assumption is that any production system requires a meaningful share of its original build cost every year in fixes, updates and small changes. Leaving it out of the budget remains the most frequent planning error.