The Economics of Software Teams: Why Most Engineering Orgs Are Flying Blind

The Economics of Software Teams: Why Most Organizations Are Flying Blind

This post works through the financial logic of software teams, from what a team of eight engineers actually costs per month to what it needs to generate to be economically viable. It also examines why most teams have no visibility into either number, how that condition was built over two decades, and what the arrival of LLMs now means for organizations that have been treating large engineering headcount as an asset.

Software development is one of the most capital-intensive activities a modern company undertakes, and it is also one of the least understood from a financial perspective. The people making daily decisions about what to build, what to delay, and what to abandon are rarely given the financial context to understand what those decisions actually cost. This is not a coincidence. It is a structural condition that most organizations have maintained, quietly and consistently, for roughly two decades.

What a Team Actually Costs

A software engineer in Western Europe costs somewhere between €120,000 and €150,000 per year when you account for salary, social fees, pension contributions, equipment, social activities, management overhead, and office space. Call it €130,000 as a reasonable middle estimate. A team of eight engineers therefore costs approximately €1,040,000 per year, or €87,000 per month, or roughly €4,000 for every working day.

Most engineers do not know this number. Many of their managers do not either. And in the organizations where someone does know it, the number rarely makes its way into the conversations where prioritization decisions are actually made.

This matters because every decision a team makes carries an implicit cost that compounds over time. Choosing to spend three weeks on a feature that serves 2% of users is a €60,000 decision. Delaying an operational improvement for a quarter is a decision with a calculable daily price tag. Rebuilding a platform because the current one feels embarrassing, rather than because customers are leaving, is a capital allocation choice that would look very different if the people making it were spending their own money.

The Internal Platform Team: What Break-Even Actually Requires

Consider a team of eight engineers whose mission is to build and maintain an internal developer platform serving one hundred other engineers. This is a common organizational structure, and it is one where the financial logic is rarely examined carefully.

The team costs €87,000 per month. To justify that cost, the platform they build needs to generate at least €87,000 per month in value for the engineers who use it. The most direct way to measure that value is through time saved, since the platform’s purpose is to make other engineers more productive.

At a cost of €130,000 per year, one engineer costs approximately €10,800 per month, or around €65 per working hour. For the platform team to break even, their platform needs to save the hundred engineers they serve a combined total of 1,340 hours per month. That is 13.4 hours per engineer per month, or roughly three hours per week per person.

Three hours per week is achievable. A well-built platform that eliminates manual deployment steps, reduces environment setup time, or removes the need for repetitive configuration work can easily clear that bar. Time saved is the most direct measure for a platform team, though value can also come from reducing outages, which carries a direct revenue impact of its own. But the question worth asking is whether anyone on that team knows this number, tracks it, or uses it to decide what to build next. In most organizations, the answer is no. The team has a roadmap driven by engineering preferences, stakeholder requests, and quarterly planning cycles, and the financial logic underlying their existence is left unexamined.

And break-even is not actually the right bar. Leah Tharin has written a sharp breakdown of the mathematics of this: a team with a 50% initiative success rate, which is already optimistic, needs its wins to cover its losses too. Leah’s calculation is growth-oriented, but even for non-growth organizations, the same investment thesis holds. Even a two-times return is not sufficient. Capital sitting in a bank carries no operational risk, no coordination costs, and no ongoing maintenance obligations. The systems a team builds will outlive the team itself, and the cost of owning, maintaining, and eventually replacing those systems is almost always larger than anticipated. The return has to cover not just the team’s current cost, but the long tail of what they leave behind.

That pushes the realistic threshold for financial viability to somewhere between three and five times annual cost. For an €87,000 per month team, that means generating between €260,000 and €435,000 in monthly value. The three hours per week calculation gets you to break-even. To clear the realistic financial bar, the platform needs to be genuinely transformative for the engineers using it, and the team needs to be ruthless about working on the highest-value problems rather than the most interesting ones.

The 3–5x threshold accounts for a typical 50–70% initiative failure rate. Successful work must cover both wins and losses. Break-even is not the right bar.

The Customer-Facing Team: Multiple Levers, Same Math

A customer-facing product team of eight carries the same €87,000 monthly cost. The levers available to justify that cost are different, but the underlying logic is identical.

If the product has an average revenue per user of €50 per month, the team needs to generate or protect the equivalent of 1,740 users worth of value every month just to break even, and roughly 5,000 to 8,700 users worth of value to clear the three-to-five times threshold.

Churn is often the most direct lever. Consider a product with 50,000 active users losing 2% monthly to churn. That is 1,000 users per month, representing €50,000 in monthly recurring revenue walking out the door. A team that identifies the primary driver of that churn and eliminates it is generating nearly €50,000 per month in protected revenue, covering most of its break-even cost from a single initiative. But that calculation requires knowing the churn rate, understanding its causes, and connecting those causes to the team’s work, and most teams are not operating with that level of financial clarity.

Activation is another lever that is frequently underestimated. If 10,000 users sign up each month but only 30% complete the activation steps that lead to long-term retention, there are 7,000 users each month who paid acquisition costs but never converted to retained revenue. Improving the activation rate by five percentage points, from 30% to 35%, converts an additional 500 users per month. At €50 average revenue per user, that is €25,000 in additional monthly recurring revenue, representing roughly 29% of the team’s break-even threshold from one metric moving in the right direction.

Sales conversion follows the same logic. If the product has a free-to-paid conversion funnel processing 20,000 trials per month at a 4% conversion rate, that produces 800 paying customers monthly. Moving conversion from 4% to 4.5% produces 900 customers, an additional 100 paying users, and €5,000 in additional monthly revenue. Small improvements across multiple levers compound quickly, but only if the team understands which levers connect to which financial outcomes and by how much.

Each scenario randomizes peak value, ramp-up speed, and decay rate — the variables most teams never measure. The faint dashed line is what you planned. The bars are what happened. Reshuffle to see how rarely the picture looks comfortable.

The Metrics We Chose Instead

Given that software teams are expensive and that their value is, at least in principle, calculable, it is worth examining why most teams do not measure anything financially meaningful.