What Truly Determines The Cost Of Custom Software
The dominant factor is never the technology stack — it is how much is still undecided. Every open question in the requirements becomes padding inside the number you receive. A supplier that cannot see what happens on the unhappy path will assume a pessimistic case. Putting two weeks into a discovery phase frequently cuts the overall figure much more than negotiating the rate.
Integrations are the second big multiplier. A feature that touches only your own data is predictable; the same screen wired into a legacy ERP is not. The unknown hides in the counterparty: poor documentation, long certification processes, data that does not match your model. Ask the estimator to price integrations separately, because that is where the numbers slip.
The requirements nobody writes down quietly rewrite the budget. A tool used by twenty people costs far less than the same idea handling thousands of external customers. Audit and compliance requirements, uptime targets, load handling, audit logging and multi-language support each add real engineering time. Put them in the brief or else expect them to arrive later as change requests.
The mix of people behind the number matters. A rate card reveals almost nothing on its own: a senior engineer at twice the price frequently turns out to be cheaper per delivered feature than two inexperienced developers who need constant review. Also ask who else is billed: php vs java spring delivery management, quality assurance, infrastructure work and analysis are real work, but they must be named rather than hidden inside a blended rate.
The build price is not what you will actually spend. Plan for hosting, subscriptions and licences, observability and a change budget for every year the livewire software runs. A useful planning figure is that a live system needs a noticeable fraction of the initial investment every year for which is better laravel or .net updates, security patches and small improvements. Ignoring this is the classic mistake.