When a company compares hiring a developer with buying development, it usually compares a salary with a quote. That comparison is wrong in both directions: the salary is a fraction of what the developer costs, and the quote, if it is a fixed price, is the entire cost of the result. This guide walks through the full cost structure of an in-house developer without inventing figures, because the figures depend on your country, market and role. The structure, however, is the same everywhere, and once it is visible the comparison with a fixed-price scope becomes straightforward. Use your own numbers in each category; the result is usually a surprise.
Why the salary is the wrong number
Salary is the most visible cost and the one that appears in budgets. It is also the only cost that an engineer produces output in exchange for. Everything else in this guide is spent either before output begins, alongside output as overhead, or after output ends. A company that compares salary with a fixed price is comparing the one productive component of the hire against the complete cost of the alternative.
The cost structure, category by category
1. Acquisition
Before a developer writes a line of code, the company has paid to find them. The components: the time of the people who write the job description, screen applicants and interview; agency or platform fees where used; the opportunity cost of senior engineers spending their days interviewing instead of building; and the cost of the positions that stay open while the search runs. The last item is the largest and the least visible. An open role delays whatever that role was going to build, and the delay has a business cost whether or not it appears in a budget line.
2. Employment overheads
On top of the gross salary, the employer pays what the law and the market require: employer social contributions and payroll taxes, which vary widely by country; pension contributions; insurance; paid holiday, sick leave and public holidays, during which the salary continues and the output stops; and any bonuses, equity or benefits the role commands. Your finance team can state the multiplier for your jurisdiction. It is rarely small.
3. Equipment, tooling and workspace
A developer needs a machine, licences for development tools, seats in collaboration and project-management software, cloud accounts for development and testing, and, if not fully remote, a desk. Individually minor; collectively a recurring line that scales with headcount and continues during holidays, onboarding and notice periods.
4. Ramp-up
A new developer is not productive on day one. Learning the codebase, the domain, the deployment process and the team's conventions takes time, during which the salary and overheads are paid in full and output is partial. Ramp-up also costs the time of the existing engineers who answer questions and review early work. The length depends on the complexity of the system and the quality of its documentation; the cost is salary multiplied by that period, plus the mentors' time.
5. Management
Every developer consumes management: one-to-ones, performance reviews, planning, prioritisation, conflict, career conversations, and the coordination overhead that grows faster than the team does. This cost is paid in the time of engineering managers and senior engineers, who are among the most expensive people in the company. Larger teams require dedicated managers, which is a further salary with its own overheads.
6. Utilisation
A salaried developer is paid for every working hour, but not every working hour produces the output the company wanted. Meetings, context switching, waiting for decisions, maintenance of systems nobody planned for, and periods between projects all reduce the share of paid time that becomes roadmap delivery. Companies rarely measure this honestly; those that do tend to find the productive share lower than they assumed.
7. Risk of a wrong hire
Some hires do not work out. The cost is everything above, paid for the duration, plus the cost of ending the employment, plus a second acquisition cycle. Even a good hiring process has a failure rate; the expected cost of that rate belongs in the comparison.
8. Attrition and exit
Developers leave. When they do, the company pays notice periods, sometimes severance, the knowledge that leaves with them, and a new acquisition and ramp-up cycle. When the company reduces headcount deliberately, redundancy costs and the effect on the remaining team's retention are added, as discussed in how to keep shipping after developer layoffs.
9. The cost of time
Finally, the cost that does not appear in any ledger: the delay between deciding that something should be built and the moment it exists. For an in-house hire that delay includes acquisition, ramp-up and the team's normal delivery pace. If the thing being built protects revenue or opens a market, the delay has a value that often exceeds every other category.
Putting the structure to work
Take a role you are considering. Write the annual salary, then estimate each category above with your own figures and your finance team's multipliers. Divide the total by the share of paid time that actually becomes roadmap delivery. The result is the real cost of one unit of in-house delivery capacity. Most companies have never calculated it, and most are surprised by it.
Now compare that with the cost of buying the same delivery as a result rather than as capacity.
What a fixed-price result costs instead
A fixed-price scope has one cost: the price. There is no acquisition, no employment overhead, no equipment, no ramp-up paid by the buyer, no management beyond confirming a scope and accepting deliveries, no utilisation loss, no wrong-hire risk and no exit cost. The price is known before work starts, and the cost stops when the scope is delivered.
Two conditions make this comparison fair. First, the scope must be specifiable, because a fixed price requires a written scope with acceptance criteria; some work (product ownership, on-call duty, customer-facing engineering) is not specifiable and genuinely needs a person. Second, the vendor must be able to hold the price without padding it, which depends on the vendor's production method rather than on goodwill.
Our prices are public: a trial build at a fixed 9,900 euros for a real piece of the plan, delivered within 72 hours of written scope confirmation and deducted in full from the main project; the first three clients receive it for 4,900 euros against a public reference; the main project is quoted at one fixed price for the whole confirmed scope. We do not publish comparisons with salaries, because the salary side depends on your market. The structure above lets you make the comparison with your own figures, and the trial build gives you a measured data point on your own backlog.
Where in-house still wins
This guide is not an argument against employing developers. It is an argument for comparing costs correctly. In-house developers are the right choice for work that requires continuous presence and accumulated context: owning the product, running production, responding to incidents, working directly with customers, and making the architecture decisions that shape the company for years. For that work, the categories above are the price of having people who know the system, and it is a price worth paying.
The mistake is to use that expensive, context-rich capacity for work that could be specified and bought as a result: a new module, an integration, a migration, a rebuild. The efficient model for most companies is a core team for the work that needs people, and fixed-price scopes for the work that needs software. The comparison page sets the two side by side; the page for companies reducing development costs describes the engagement; the request form is the first step.
Frequently asked questions
Why do you not publish actual cost figures?
Because they depend on country, market, seniority and role, and any single figure would be misleading for most readers. The structure of the costs is universal; the figures are yours to fill in with your finance team's multipliers. Our own prices, by contrast, are fixed and public.
What is usually the largest hidden cost?
For most companies, the cost of time: the delay between deciding to build something and its existence, which for an in-house hire includes acquisition and ramp-up. The second largest is usually management and coordination, paid in the time of the most senior people.
Does a fixed price have hidden costs of its own?
The buyer's costs are writing or confirming a scope, answering written questions, and reviewing deliveries. Those are real but small, and they are costs the buyer would incur for in-house work as well. There are no acquisition, overhead, utilisation or exit costs.
Is a fixed price not just an hourly rate with contingency built in?
From a vendor whose output per unit of time is uncertain, often yes. From a vendor with a repeatable production method, the price reflects the scope rather than padded hours. The way to find out which kind of vendor you are dealing with is a small, real, fixed-price piece of work on your own code.
How should we compare the two in a budget proposal?
State the fully loaded cost of the in-house capacity for the period, divided by its productive share, next to the fixed price of the scope. Add the cost of delay on the in-house side where the scope protects revenue. Present the trial build as a bounded first step so the decision does not have to be made on projections alone.
Which roles should stay in-house regardless of cost?
Product ownership, operations and incident response, customer-facing engineering, and the architectural stewardship of the company's core systems. These need presence and accumulated context. Specifiable development work, by contrast, can be bought as a result.