For CEOs: The Hidden Costs of In-House Software Development

Should we outsource our development? It’s a common question from every CEO I’ve ever worked with. Usually driven by seeing the cost of an in-house software development team. And since they’re just writing code, why couldn’t cheaper people do the same job just as well?

The short answer: it’s a balancing act between ownership, culture, and long-term concerns.

I’ve been in the trenches long enough to have seen the good, bad, and ugly. I’ve worked through many combinations of in-house employees, nearshore partners, offshore, staff augmentation models, and full project outsourced delivery.

Any of the options above represent trade-offs in your technology strategy. And that ultimately impacts your ability to deliver and support the product your customers pay for

Let’s start with some bad news. The cost of an in-house software development team is quite a bit more than the payroll number. Even if you account for the typical employee overheads of tax, healthcare, and other perks.

So today, we’re going to pull back the curtain on these hidden in-house software development team costs. Understanding the full picture of development costs is crucial for making informed decisions about your tech strategy.

I wrote this considering both a UK and US perspective. Adjust for your local regulations and cultural tweaks, but the principles will hold.

Table Stakes: Basic Costs of An In-House Software Team

This is broadly what most people would consider the “cost” of an engineer.

Base Engineer Salaries: Just the Tip of the Iceberg

In major tech hubs like London or San Francisco, a senior developer’s base salary can easily start at £90,000 or $200,000 respectively. But that’s just the starting point of course,

Benefits and Taxes: The Hidden Multipliers

1. Health Insurance: In the US, this is a major expense, often adding 20% to the base salary. In the UK this is your NIC running at 13.8%.
2. Retirement Contributions: 401(k) matching in the US or pension contributions in the UK can add another 3-15% to your costs.
3. Payroll Taxes: In the US, factor in Social Security and Medicare taxes. In the UK, don’t forget about National Insurance contributions.
4. Paid Time Off: Both countries mandate paid leave, sick days, and often parental leave. 

Back of the envelope, add to the gross base salary 20% in the UK and 30% in the US to get a good enough ballpark number.

Perks and Incentives: The Talent Attraction Tax

In today’s competitive tech landscape, base compensation is just that: base. While not deal killers per se, people typically also expect:

1. Bonus: Performance-based bonuses can range from 10-30% of base salary. (typically more a US item)
2. Stock Options or Equity: A must-have for startups to attract top talent. Ideally under a tax-friendly scheme like EMI in the UK.
3. Professional Development: Budget for conferences, courses, and certifications; or at least some option to learn and grow on company time.
4. Wellness Programs: From gym memberships to mental health support, private healthcare. 
5. Office Perks: Think free meals, game rooms, or onsite childcare.

I often say engineers care about a balance of money and interesting problems. So while perks and incentives go some way towards that, you need to get the problems right too. We’ll get to that later!

The Real Math – Costs of An In-House Software Team

When you add all these elements together, the true cost of a single developer can be 1.5 to 2 times their base salary. So, that £80,000 developer in London or a $150,000 developer in San Francisco? They’re costing you £120,000-£160,000 or $225,000-$300,000 per year, respectively.

Not all of that is monthly cash outflow, but it is all cost in some way.

And remember, we’re talking about building a team here. Multiply these costs by the number of developers you need, and you’ll quickly see why the financial implications of in-house development can be staggering. Read more about engineering team costs and managing your software finance.

Let’s look at another often-overlooked aspect of in-house software development: the ongoing investment in equipment and infrastructure.

Ongoing Equipment and Infrastructure Costs For In-House Software Development

The base salary & related costs are easy to compare in-house vs outsourced. But that just buys you a body, frankly. So let’s look at some necessary tools of the trade.

Here’s my breakdown (I will just use the $ tag for convenience): 

Developer Workstations: More Than Just a Laptop

Developers need a high-performance setup. I could give you a long argument. 

But the short version is this: The tools used in development put heavy demands on the machine they run on, both on memory usage and raw CPU power. The next big ticket item is to screen real estate to have code and run applications side by side. 

1. High-end laptops or desktops: Expect to spend $2,000-$3,000 per developer.
2. Multiple monitors: Usually two per developer, adding another $400-$800.
3. Ergonomic furniture: A good chair and desk can cost $600-$1,200 per workstation. Though that’s probably somewhere between equipment and perk.

Infrastructure: The Foundation of Your Development Operations

So we have a body with a laptop. Next: a place to test the product in a production-like environment. 

Development tools and infrastructure of course aren’t free. Annual costs per developer often include:

1. Dev tools, code editors: $600-$1,200 / year
2. Cloud services subscriptions: This is another topic of its own. I will have another article to cover this. Absolutely a topic that a qualified CTO should be aware of and able to explain your cloud strategy and KPI to you within a few sentences.
3. Dev & test setups: Separating this from cloud services. This is the cost you have for running in a production-like setup. Depending on the complexity of your product this can easily add up to $1000-2000 / year.
4. Security measures: This could be 0, but in practice, you want some money aside for basics like backups, and VPN access, …. 

The Upgrade Cycle: Keeping Pace with Technology

Here’s the kicker: these aren’t one-time costs.

While a 3-year-old laptop might be enough for browsing the web and editing a Word document, it usually doesn’t cut it for a great experience in development tools.

• Workstation upgrades every 2-3 years
• Annual software subscriptions, cloud & dev environments, … top-up or renew

When you factor in these ongoing costs, you’re looking at an additional $2-$5k / year easily.

Time Costs in In-House Software Development

So far the costs were all some form of cash outflow. Now let’s talk about the most precious commodity: time.

And more importantly, the effective use thereof.

Recruitment: A Time-Intensive Process

Finding the right developers is challenging and time-consuming. On average, it takes:

• 30-40 days to hire a software developer in the US
• 50-60 days in the UK tech hubs like London

That’s the time it takes to get a bum-on-seat, as the British put it. It also takes time from your existing staff to screen CVs, interviews, consolidate notes, etc. (sidenote: I can help with that)

This process involves:

1. Understanding what talent you need and why (How well do you understand the rationale behind hiring for a specific technology role when you approve the budget?) 
2. Writing job descriptions, reviewing resumes
3. Conducting interviews
4. Negotiating offers

Onboarding: Getting New Hires Up to Speed

Once you’ve hired a developer, they need time to do stuff. Typical onboarding timeframes:

• 1-2 months for junior developers
• 2-4 weeks for experienced developers

This assumes that your tech team has a great knowledge-sharing culture and adequate documentation and onboarding system. In practice, it’s probably closer to 3 or even 6 months before engineers are fully embedded. 

During this period, you’re of course paying full salary. Additionally, your existing team members spend time training new hires, reducing their productivity. Double whammy!

In-House Software Team Building and Management

Engineers are no different from any other team in the company. If you want a group of random people to perform as a team, you need to invest in them becoming a team.

While the specific activities will vary between departments, it’s the usual

• Team building activities: 1-2 days per quarter
• Regular team meetings: 2-4 hours per week
• One-on-one sessions: 1 hour per team member per week

Ongoing Training and Skill Development

Technology evolves rapidly. Keeping your team’s skills current requires:

• Conference attendances: 2-3 days per developer per year
• Online courses or workshops: 4-8 hours per month per developer
• Internal knowledge-sharing sessions: 2-4 hours per month

This ongoing training is crucial. In part because it means your team, and therefore your product, stays up to date. But it also plays into the “interesting problems” I mentioned earlier.

Offboarding

People leave. For a variety of reasons. The average tenure in engineering roles is about 2 years. 

Most of the code I wrote in 2014 is still running in production today in 2024. This means that by now 5 different engineers have had to figure out what that code is trying to do. At least 4 of those without direct access to me.

To counter this I am a big advocate of documenting decisions. Not just what was decided, but also why. And I consider that part of the job of an engineer. Not my favorite part, but part nonetheless. 

One of the tenets I wrote for an engineering strategy was “think about the next engineer”. By the time we got to offboarding engineers, we skipped all the typical “I need a brain dump from you”. Frequent leavers are part of managing an engineering team. Don’t fight it, set yourself up to handle it.

The Impact on Development Timelines

The point I’m making here is that “time spent typing code” is a poor measure of engineering productivity. I wrote before that typing code is 20% of the job. However, all the other tasks lead to a team that can consistently produce your product. That is time worth spending.

Outsourced companies have the same dynamics to cope with. The main difference is that they are hidden from you. It’s not like they suddenly spend 8 hours coding if you’d want to stick to that poor metric.

Scalability Challenges in In-House Software Development

Or as I prefer to think of: optionality.

Scaling up is hard but often done with enough enthusiasm to overcome pain. We’re growing, there’s money in the tank, we’ll get more done eventually. That’s a great case for a long-term commitment to an in-house team. 

Sometimes though you need a specific project done. That’s where some flexible capacity from contractors is useful.

The more interesting question is what happens when you scale down full-time teams. Few people do this with enthusiasm. It’s a balancing act between morale and core skill preservation; staving off the snowball effect; and not burying the company in costly exit packages and legal exposure. Been there done that. My nickname at one company was “the cleaner” because that is exactly why I was brought in.

It’s also the key reason why I spend extra time reading exit and break clauses in contracts. I know how to get out before I get in.

The Cultural Impact of In-House Development Teams

The direction of scale and direction of morale are closely related. However, even by adding a new team, you can make morale go down. This is where culture and positioning come in. Here’s how I reshaped engineering culture for my client.

The ‘Us vs. Them’ Trap

The classic pattern, I’ve seen many times. In-house teams are set on their routine, and social structure, and are generally happy working together. Bring in the “outside” team without much context.

Let’s say we have team A (in-house) and team B (outside).

1. Team B tries to get access to code, and documentation, … and generally learns to understand the existing product
2. Team A thinks B is slow, doesn’t get it, and generally does not contribute much
3. Team B thinks A is overly harsh and doesn’t want to share knowledge
4. Team A and B slowly ask less questions of each other. They now talk only in mandatory meetings. Bonus points in this scenario if one team isn’t a native speaker of the language of the other
5. Team B finally released a feature, with a small bug. Team A decides it’s poorly implemented by “them”. Blame all around.

Sure, shortened for effect. But it’s very easy to fall into an us vs them scenario. It’s the default position if leaders don’t actively try and prevent it in my experience.

Bridging this gap is something I’ve spent a large part of my career on. Whether that’s post-M&A integration, outsourcing, onboarding 3rd parties, embedding consultants in a client’s org, …. They all require the same things as a leader:

1. Time investment: Building a team takes time. Don’t deprioritize it. Have those days out, and bring people together. Make an effort
2. Leadership mediation: An impartial voice who can sit in the middle and see both sides of the story. Remind people they share the same goals, and keep them talking. 
3. Hiring considerations: You’ll need to prioritize soft skills and cultural fit alongside technical skills, potentially limiting your talent pool. I would especially focus on language here. Full fluency in a shared language is non-negotiable.

The key is understanding these potential pitfalls so you can make an informed decision for your unique situation.

The Bottom Line

Don’t get me wrong – in-house development can be the right choice for a lot of companies. But as a CEO, it’s crucial to go into this decision knowing the potential downsides and discuss openly with your CTO.

I suggest you take a look at your near-term business goal and the long-term strategy. 

Are you planning to grow fast in the next few months, or do you prefer to remain small for profitability? Are you prepared for the ongoing investment of time and resources that in-house development requires? Or would your business be better served by a more flexible outsourcing model?

As I said early on: it’s finding a balance that’s right for you. Have that conversation.