The hidden costs nobody tells you when building or maintaining a tech team

The CTO opens the annual budget spreadsheet and sits in silence for almost a full minute.

He had approved a budget of €280,000 for the development team: five developers, agreed salaries, everything under control.

The number in front of him is €510,000.

This is not an accounting error. It is the result of years of budgets built by looking at salary figures alone, instead of at real costs.

The true cost of a .NET development team is almost double the gross salary, and most companies discover this only at year-end review, when it is already too late to act.

This guide is for those who manage technical teams and want to stop being surprised by the numbers at the end of the year.

We will look at where the money goes that never appears in contracts, why certain decisions that seem like savings turn out to be mistakes within a quarter, and how to build a team structure that produces real value for every euro invested.

If you want an analysis built around your specific situation, you can request it directly. I am Matteo Migliore, and I work with teams that need clarity, not another generic report.

Why the real cost of a .NET developer is almost double what you approved

Consider a concrete example: a senior .NET developer on a gross annual salary of €65,000, a figure in line with the Italian market in 2026.

The moment you sign the contract, you have already set in motion a series of costs that do not appear in that figure, but which you will pay regardless.

• The first layer is mandatory by law. Employer social contributions in Italy amount to approximately 31–32% of the gross salary, and the statutory severance fund adds a further 8.33% that must be set aside each month. Even before the developer writes a single line of code, this already adds around €25,000 on top of the gross salary.
• The second layer covers operational provisions: the category that IT budgets tend to treat as marginal, until it all adds up. Meal vouchers, supplementary health insurance, a laptop to refresh every three or four years, licences for Microsoft 365, Visual Studio or Rider, Git: taken individually, these seem like minor items. Together, they come to between €5,000 and €8,000 per developer per year. On top of that come team-level licences: Jira, Confluence, Slack, Azure DevOps, APM tools, cloud development and test environments. These too rarely appear precisely in the approved budget, but they are paid all the same. There is also one line that, by 2026, has ceased to be optional: AI-powered development tools. A developer who works without a code-writing assistant, without access to an advanced language model for solving complex problems, and without AI testing tools, starts at a structural disadvantage compared to those who have them. This is not a matter of personal preference: it is a productivity gap that falls back on the company in the form of longer timelines and lower quality. The cost of these tools, between GitHub Copilot, Claude Pro or ChatGPT and similar services, runs between €600 and €1,200 per person per year. A modest figure relative to what it returns, but one that almost no IT budget explicitly accounts for.
• The third layer is professional development. Training, cloud certifications, e-learning platforms, one technical conference per year: it is difficult to come in below €3,000–4,000 annually for a senior developer who wants to stay current. Add to this the recruitment and selection costs, which amortised over the average tenure in the company weigh in at another €3,000–5,000 per year.
• The fourth layer is the one nobody includes in the budget: the cost of coordination. A team lead or CTO spends on average one to two hours per week per developer on code reviews, alignment, project meetings and priority management. At an opportunity cost of €80 per hour, this amounts to €4,000–8,000 per person per year that does not appear in any personnel cost line. The total direct cost of that senior on €65,000 sits between €111,000 and €125,000 per year. Between 70% and 92% more than the gross salary.

On a team of five with a similar profile, the gap between "perceived cost" and "real cost" exceeds €250,000 per year.

This is not an exceptional case: it is the norm, and it almost certainly reflects your team's situation as well.

At this point the question is no longer theoretical. It is straightforward: how much are you underestimating today, without knowing it?

In a 30-minute call we analyse your team together and rebuild the real cost, line by line.

Not assumptions. Numbers. Yours.

You will immediately see where you are losing margin, and where you can recover it without changing your team.

Two juniors instead of one senior: why the obvious saving almost never exists

It is a calculation almost every technical manager runs at least once: one senior at €65K gross, or two juniors at €30K each.

Same budget, two people instead of one.

On the surface it looks like a smart optimisation. In practice, it is almost always a mistake that is paid for in the following quarters.

The problem is not raw productivity, but the total cost of the outcome.

Two junior developers produce around 60–70% of the useful code of a senior, generate considerably more bugs that someone will have to fix, and require 20–30% of a tech lead's time for supervision, code review and ongoing mentoring.

That time has a cost: if your senior developer or architect spends one day a week keeping two juniors afloat, you are paying that person to not do architectural work.

There is also a less obvious but more expensive long-term effect: technical debt.

Code written without experience of architectural patterns, without a clear understanding of the consequences of design decisions, accumulates in a codebase that becomes progressively harder and more costly to change.

Not immediately, but over the following 12 to 18 months, when every new feature takes twice as long as expected because the underlying code cannot support it.

The real total cost of two juniors is often 20–30% higher than that of a senior, already in year one, before even accounting for the technical debt they generate.

The seniority breakdown is worth keeping in mind, not as a rigid hierarchy but as a reference for team composition decisions.

A junior developer (0–2 years) costs the company between €42,000 and €56,000, but reaches full operational autonomy after 8–10 months of onboarding.

A mid-level developer (3–5 years) costs between €58,000 and €80,000 and becomes fully operational in 4–5 months: this is the best cost-to-output ratio for standard development volume.

A senior developer (6–10 years) costs between €85,000 and €120,000 but is productive within 2–3 months and reduces the bug rate by 40–60% compared to a junior.

An architect (10+ years), at a cost between €125,000 and €190,000, should not be thought of as an "expensive developer" but as a productivity multiplier for the entire team: architectural decisions made at this level shape the efficiency of everyone else for years.

The optimal structure for a mid-sized company running a .NET stack is not the one with the most developers, but the one with the right seniority distribution.

A team of five with one architect, two seniors and two mid-level developers produces more value, at equal or lower cost, than a team of eight juniors.

And above all it does so sustainably, without accumulating technical debt that will be paid for in the next three years of budgets.

What does it really cost you every time a developer leaves the team?

When a developer leaves, the first instinct is almost always to focus on recruitment: how long will it take to find a replacement, how much will the agency charge?

That is the visible part of the problem.

The invisible part, the one that never appears in any financial report but is felt in the months that follow, is almost always heavier.

Start with the search itself.

A specialist recruitment agency charges a fee of 15–25% of the candidate's gross salary: on a senior at €65K, that means €10,000 to €16,000 in direct costs.

If the search is handled internally, the cost does not disappear: it transforms into hours of HR, management and technical screening time, which for a senior-level search is estimated at 200 to 400 hours of work.

Then comes the onboarding period: the 6 to 9 months during which the new developer operates at reduced productivity, between 30% and 70% of their potential, generating a value gap of €20,000 to €40,000 compared to someone already up to speed.

But the most underestimated item is the institutional knowledge that walks out the door.

A senior developer with three or more years at a company takes with them the knowledge of the codebase, the architectural decisions made over time and the reasoning behind them, and the specifics of the business domain.

None of this is comprehensively documented anywhere, and the cost of reconstructing it, through reverse engineering of the code, questions to remaining colleagues, and mistakes made by someone who does not know what they do not know, is hard to quantify but is estimated at between €15,000 and €25,000 for each senior departure.

In total, replacing a senior developer costs between €50,000 and €100,000.

On a team of five with an annual turnover rate of 25%, which in the .NET market is a conservative estimate, this means spending between €50,000 and €100,000 every year simply to stand still.

What actually reduces turnover

Industry surveys, including those conducted annually by Stack Overflow across hundreds of thousands of developers, consistently point to the same conclusion: developers do not leave primarily because of salary.

The leading cause of attrition is uninteresting work or outdated technology.

This is followed by a lack of growth opportunities, poor management, and an imbalance between professional and personal life.

Salary ranks fourth.

This has an important practical implication: reactive pay rises, the kind offered to retain someone who has already decided to leave, have limited and temporary effectiveness.

Investing in modern technology, in concrete career development pathways and in technical autonomy reduces turnover by 30–50%, with a return on investment that no compensation adjustment can match.

Are you losing money to turnover without being able to quantify it precisely?

Outsourcing or in-house team: the break-even point almost nobody calculates correctly

The question "outsourcing or in-house team?" tends to divide opinion in almost every company, usually because whoever raises it already has the answer in mind and is looking for confirmation.

The problem is that both positions look at a single number, and the wrong one at that.

A developer sourced from an external software development firm of average quality costs between €400 and €800 per day, or €50 to €100 per hour.

Compared to an employee's net take-home pay, this looks like an enormous cost.

Compared to the true total cost of an employee, including all the layers we have covered, the difference narrows considerably.

For a 12-month full-time project, the outsourcing cost sits between €80,000 and €160,000.

The cost of an in-house senior for the same period is between €95,000 and €110,000, but to this must be added the turnover risk: if that person leaves at the end of the year, the knowledge they have accumulated leaves with them.

The break-even between outsourcing and in-house is reached at around 18 to 24 months.

Below that threshold, outsourcing is almost always more efficient in terms of total costs. Beyond it, the in-house team becomes more advantageous for strategic projects, because the accumulated knowledge stays within the organisation and the per-person cost falls over time.

The hybrid model and its hidden risks

The configuration that works best for most mid-sized companies running a .NET stack is a hybrid one: one or two in-house people with a strategic profile, an architect or senior developer with architectural vision, who own technical decisions and oversee quality, supported by an external team for execution.

Critical knowledge stays within the company, fixed costs remain contained, and scalability is flexible. The cost of the in-house profile, between €90,000 and €110,000 per year, is more than justified by the impact it exerts on an external team billing €200,000 to €400,000 annually.

But outsourcing carries risks that do not appear in the contract, and which are worth factoring in explicitly.

The first is vendor lock-in: if all knowledge of the system resides with the external vendor, at contract renewal your negotiating position is close to zero.

This dependency almost always translates into a rate increase of 15–30% at the second contract, when switching vendors would cost more than accepting the new terms.

The second risk is the cost of coordination: the friction between the in-house team and the external vendor, requirements management, and the continuous alignment on priorities absorb 10–20% of your internal points of contact's time. It is an opportunity cost that appears on no invoice, but is as real as any other budget line.

What is the code you have already written costing you every day?

Technical debt does not appear in any financial report. It has no line in the IT budget. It generates no invoice.

But it is paid every day: in every release where a feature takes twice as long as expected, in every bug that reappears after having already been resolved, in every new developer who spends months trying to understand a codebase with no externally readable logic.

Translated into numbers: if 30% of the team's time goes into maintenance, bug fixing and workarounds on legacy code, and your team costs €500,000 per year, you are paying €150,000 annually without producing any new value.

And this percentage, without deliberate intervention, tends to grow over time, not to shrink.

The practical rule that emerges from experience across dozens of .NET codebases in production: every year of deferred refactoring adds approximately 15–20% to future development costs.

A codebase that today requires €400,000 per year in maintenance and development will, after three years of unmanaged accumulation, require €600,000 to €700,000.

At this point the question changes. It is no longer "do we have technical debt?"

It is: how much is it costing us every month, without our seeing it?

In a 30-minute call we analyse your codebase from an economic perspective: how much time is absorbed by maintenance, how much value is being lost, and where to act to reverse the curve.

Not theory. Real numbers on your project.

How to tell whether your technical debt is a team problem or a business problem

Not all technical debt is the same, and treating it as an undifferentiated mass leads to poor decisions.

Deliberate debt, accepted intentionally to meet a deadline with a plan to address it later, is manageable if tracked.

Accidental debt, accumulated without awareness because nobody had the experience to recognise it as it formed, is the kind that becomes a structural obstacle.

The signals that technical debt has stopped being a technical problem and is becoming a business problem are three:

• The average time to complete a new feature increases quarter after quarter, without the team having grown.
• Every change to one area of the code produces unexpected behaviour in unrelated areas.
• Development estimates become systematically unreliable, with regular variances of 50–100% against expectations.

If you recognise at least two of these three signals, technical debt is already affecting the competitiveness of your product, not just the well-being of your technical team.

The connection with modernisation is direct: the cost of legacy software is not just an outdated technology stack, it is the technical debt accumulated over years that makes it unsustainable in the long run.

How to build an IT budget that holds no surprises at year-end

The primary cause of IT budgets that fall apart is not the bad intentions of those who built them.

It is the planning model.

Most companies build the IT budget top-down: they start from a number acceptable to the CFO and distribute it downwards, trying to make everything fit.

The real costs of a technical team, however, work in exactly the opposite direction.

A credible IT budget for a .NET team is built by summing four distinct components, estimated separately rather than derived from a pre-set total.

The first component is personnel cost at real cost, not at gross salary.

As we have seen, the correct multiplier is between 1.7 and 1.9 times the gross salary. Any figure below that is an underestimate that will be corrected at year-end.

The second component is the technology infrastructure: cloud, licences, development and monitoring tools.

In a .NET team of five people using Azure as the primary platform, this item typically falls between €15,000 and €40,000 per year, depending on application complexity and the volumes managed.

The third component is the reserve for technical debt and maintenance, which if not planned for will be paid regardless, but in an emergency and inefficient manner.

The practical rule: at least 15–20% of the total development budget must be explicitly allocated to maintenance, refactoring and technical debt reduction.

This is not a cost "if needed": it is a certain cost. It is simply a matter of when and how it is spent.

The fourth component is the buffer for turnover. With an attrition rate of 20–25% in the .NET market, the cost of at least one replacement on a team of five is statistically almost certain within any 12-month period.

Setting aside 10–15% of personnel costs for this eventuality is not pessimism: it is sound planning.

If your budget today is built to "make the numbers fit", it is not a budget. It is a bet.

The problem is that you find out only at year-end review, when it is too late to correct it.

In the 30-minute call we work through a real case: yours.

We rebuild the budget from actual costs and translate it into figures that make sense even for a CFO.

At the end, you have one concrete thing: a defensible budget, before it becomes a problem.

How to present the IT budget to the CFO

CFOs do not reject IT budget requests because they do not understand technology. They reject them because CTOs tend to present costs without connecting them to measurable business impact.

The difference between a request that is approved and one that is rejected almost always comes down to the translation between technical cost and economic impact.

Consider the difference between "I am requesting €80,000 to upgrade the CI/CD pipeline" and this: "Our current release process requires 3 manual hours per deployment, at two releases per week. That is over 300 senior-level hours per year. This investment frees them up, generating a direct saving of €18,000 to €20,000 annually.

Added to this is the elimination of the risk of production outages, which in 2025 already cost us €30,000 across two incidents." That is the difference between a technical conversation and a business conversation.

The second is far more likely to be approved.

The KPIs every technical manager should review every quarter

Measuring the productivity of a development team is hard, and many companies end up measuring what is easy: story points completed, lines of code written, number of commits, rather than what is actually useful.

The metrics that really matter are those that connect the team's work to the value generated and the cost incurred.

Cost per released feature is the starting point: divide the team's monthly cost by the number of features actually in production and in use by users.

Not those completed in the sprint, not those in staging: those that users are actively using.

This KPI immediately reveals whether the team is building the right thing or getting lost in work that never reaches production.

Lead time and cycle time tell a different but complementary story.

Lead time measures the time from idea to production deployment. Cycle time measures only active development time.

The gap between the two reveals how much time is lost in waiting, approvals and internal bureaucratic processes.

In a well-organised .NET team using Azure DevOps, the average cycle time for a medium-complexity feature should be under five working days.

If it exceeds ten, the problem is in the process, not in the people.

Post-release defect rate is the thermometer for real code quality, as it actually is rather than as it is perceived internally.

A rate that increases quarter after quarter is the most reliable signal that technical debt is structurally eroding the team's productive capacity.

DORA metrics, standing for DevOps Research and Assessment, are now the industry standard for evaluating the performance of a technical team: deployment frequency, mean time to recover from an incident, change failure rate, and recovery time.

High-performing teams deploy multiple times per day, restore services in under an hour, and maintain a change failure rate below 15%.

A .NET team with a well-configured pipeline on Azure DevOps can reach these benchmarks within 6 to 12 months of systematic work.

Finally, effective capacity utilisation: how many hours each week every developer spends writing code that will reach production, compared to time in meetings, approval processes, administrative tasks and rework.

In a healthy team, a realistic target is 60–70% productive time.

If it drops below 50%, hiring more people does not solve the problem: it only solves the wrong one.

How to reduce team costs without compromising quality

Reducing the costs of a technical team does not mean cutting people or compressing salaries.

It means increasing the value produced per euro invested, which often means spending better, not spending less.

Team composition is the starting point.

An efficient team for a mid-sized company running a .NET stack is not the largest one: it is the one with the right seniority distribution. An architect who owns technical decisions, two or three seniors who execute with autonomy, one or two mid-level developers for standard development volume.

This configuration produces more value and generates less technical debt than a larger team weighted towards junior profiles.

AI-powered development tools offer the highest short-term ROI of any available lever.

GitHub Copilot returns on average two to three hours per week per developer. On a team of five, that is between 500 and 800 hours recovered per year, equivalent to €25,000 to €40,000 in value at the same headcount.

The cost of the tool is a small fraction of that return.

Automating the release cycle has a similar impact over the medium term.

A well-configured CI/CD pipeline on Azure DevOps or GitHub Actions reduces manual deployment and testing time by 40–60%, freeing hundreds of hours per year for higher-value work.

The initial investment is almost always recovered within six months.

Investing in architecture is the lever with the highest long-term ROI, even though it is the first one budgets tend to cut.

Allocating 15–20% of the development budget to architectural quality and deliberate technical debt reduction lowers maintenance costs by 30–50% over the following three years.

This is not a cost: it is the most effective way to reduce team costs in future budgets.

Near-shoring is an option worth evaluating for roles that are less critical from a business domain perspective.

Developers based in Romania, Poland or Serbia, countries with high .NET competence and well-integrated into European working standards, cost 30–50% less than their Western European counterparts at equivalent technical skill.

The condition for this to work is keeping in-house the people who own architectural decisions and the relationship with the business: the savings on execution roles are only meaningful if technical direction is solid.

The companies that manage technical team costs most effectively in 2026 are not those that spend the least.

They are those that measure what matters: value produced per euro invested, not headcount.

A team of four well-composed people with good tools and a sound architecture produces more value than a team of eight mismatched people carrying years of accumulated technical debt.

And in most cases, it costs less too.

The question to ask every quarter is not "do I have enough developers?" but "am I extracting maximum value from every euro I am investing in the team?"

If the answer does not come immediately, there is likely a margin of optimisation that you are not seeing because you are too close to the problem to see it clearly.

An optimisation of even 20% on a team of five is worth between €80,000 and €100,000 per year that stops leaving without returning as value.

Every quarter that passes without a structured analysis is a quarter in which that gap remains open.

The IT Director of one of the largest software companies in northern Italy, after working with me, wrote: "From a programming perspective, he is one of the most skilled experts I have ever encountered. I recommend Matteo to anyone managing a team who wants to raise the architectural bar."

The fastest way to identify where the margin for optimisation lies in your specific case is an external analysis, free from the cognitive biases of someone immersed in the problem every day.

What emerges from a 30-minute call often changes the way you look at the next year-end review.

You have read through numbers, dynamics and mistakes that you probably recognise in your own team.

But there is one point that makes a real difference: until you put your own numbers on the table, they remain hypotheses.

A well-conducted analysis on a team of four to six people almost always surfaces between €80,000 and €120,000 in annual inefficiencies.

Not theory. Real margin.

In our call we work with your data:

• Team structure
• Real costs
• Points of waste

At the end you have one thing: clarity on where you are losing money and what you can do about it immediately.

If it makes sense for both of us, we continue.

If it does not, you still have numbers you did not have before.

No pressure. No funnel. Just a proper analysis, done right.