The single largest cost driver is never technology — it is unclear scope. Every ambiguity in house vs outsourced development team the brief becomes a buffer somewhere in the quote. A vendor that does not know what is rag and langchain happens on the unhappy path will assume a pessimistic case. Investing a few days in a discovery phase frequently cuts the overall figure much more than haggling over hourly rates.
Connections to other systems remain the second big multiplier. A feature that touches only your own data is low risk; the same feature connected to a payment provider and a CRM is another matter entirely. The unknown lives in the other system: poor documentation, waiting on someone else’s team, inconsistent data. Ask each bidder to price integrations separately, as that is where the numbers slip.
Non-functional requirements quietly rewrite the budget. An application used by a small internal team is a very different build from the same idea serving a hundred thousand users. Security reviews, high availability, load handling, audit logging and multi-language support all add weeks of work. Put them in the brief or else expect the estimate to move later.
The mix of people behind the number matters a great deal. A rate card reveals little on its own: a senior engineer at a premium rate can be cheaper per delivered feature than two inexperienced hire developers in germany who need heavy code review. Ask as well which roles are billed: delivery management, testing, release engineering and UX design are legitimate costs, but these should be named rather than hidden inside a blended rate.
The quoted figure is rarely what you will actually spend. Expect hosting, paid APIs, monitoring and a change budget each year. A useful planning figure says that a live system needs a meaningful share of its original build cost every year in fixes, flutter consulting services updates and small changes. Leaving it out of the budget has always been the most frequent planning error.