The economics of internal developer platforms
Platform Engineering Primer, Part 6. The sixth in a series of articles exploring how developer platforms benefit modern businesses.
Join me in examining the intricacies of platform engineering. Let's take it apart and find the effective strategies, the most practical ways of working and the technologies that fit your needs and circumstances. Above all, I want to explore how internal developer platforms are the gateway to modern enterprise success.
What is the value of an internal developer platform? It's hard to grasp something so theoretical, especially if this is your first attempt to define the value. Most of us can describe what a platform is, what problems it solves, and maybe even how we could build it. But let's face it, quantifying the monetary value of a platform to our business is a daunting task.
This article provides concise, digestible information to help you build an economic case for platform engineering in your organization. Once built, the case clarifies when the platform's value will be realized and how much time will be freed up for software developers to focus on higher-level problems and deliver greater value. Finally, it allows us, the platform builders, to articulate the value of our work.
Platform economics is a powerful, positive argument
Both product and engineering leaders take great care to justify and prioritize the money they spend. This process can raise doubts about the value or timeliness of platform engineering. Doubts that often prevent organizations from moving forward with platform engineering include:
In our case, building a platform will take too much time and effort.
It is too costly to build and operate such a platform.
Our in-house engineering is not capable of building a platform. And finding the right engineering talent will be hard and expensive.
It’s challenging to quantify the value of technical platform products. We struggle to sell this idea to our executives.
A clear demonstration of the economics of an internal developer platform is probably the most effective way to resolve common concerns in this area.
To understand platform engineering's value beyond economics, I recommend reading my previous article: Unveiling success through platform engineering.
In a moment, we'll look at how to build a business case for a platform. But first, let's take a quick look at whether investing in a platform makes sense for your business (it doesn’t always).
When is investment in platform engineering justified?
The economics of building an internal developer platform are directly related to economies of scale. The larger the organization, the more it makes sense to build a platform. From this perspective, the benefit comes from increasing the capacity of a platform to handle more developers and more workloads.
It’s worth noting that the value of the investment is largely determined by the goals of the platform. These goals typically arise from intentions such as:
Consolidating resources to optimize costs of ownership
Improving level of standardization among the engineering teams
Satisfying regulatory compliance requirements in a rapidly evolving market
Improving developer productivity and satisfaction
And so on.
Justifying an investment in platform engineering boils down to two things:
Increased leverage so you get better results while spending less money.
Creating a ripple effect so you improve the world around you.
In order to use either of these arguments effectively, and especially the first one, you need to provide the specific monetary information that makes the return on investment tangible. You should consider building IDP if the following equation is true:
cost of building and running the platform should be lower than
average costs of “you built it, you run it” x number of teams
In the next section, I'll break it down into a clear financial justification.
How to calculate the ROI of platform engineering
The image below is a screenshot of a return on investment calculation which demonstrates the financial benefits of adopting a platform strategy.
$3 741 360,00 Nett effect with 156,50% ROI for a platform onboarding ten teams a year for a lifetime of three years.
Under these assumptions, the simplified calculation shows a break-even point is achieved at 17 developers. This means hosting roughly three development teams on the platform is enough to justify the costs.
Inputs required to calculate ROI
Please note that these are averages that I've seen used in the industry and by our customers at VirtusLab. They may be far from your reality, which means you need to do your homework before they are right for you. Consider conducting an internal survey to get a better understanding of your version of the numbers here.
Average developer rate: This represents how much a developer earns in your organization. The average developer rate in Europe is $45/hour, $1800/week, $7560/month (from CEE salary guide, Hays report, Talent.io report).
Number of development teams to onboard per year: This represents how many teams will be onboarded to the platform. Depending on the size of the organization, this can range from a handful to hundreds of development teams. In general, the larger the number of teams using the platform, the greater the economies of scale.
Average number of people on the development team: Based on personal experience, a team of six people is a sweet spot for a team with cross-functional expertise.
Average platform engineer rate: for the sake of this calculation, let's assume platform engineers earn $45/hour, $1800/week, $7560/month (from CEE salary guide, Hays report, Talent.io report). In reality, these people earn slightly more than developers because their skills range from software engineering to cloud engineering, which are in high demand. However, reports are not accurate and you have to do your math here.
Platform team size: It depends on the size of the investment. I have seen many examples of platform teams ranging from relatively small - around 3-5 people - to large teams of 20 people responsible for multiple areas of the business. Let's say a team of 6-10 people is sufficient to build the platform and support multiple development teams. For ease of calculation, roles such as engineering manager or product manager are included in this number.
Average infrastructure overhead costs per development team: Costs typically include the infrastructure control plane, automation workflows, observability stack, security tools, and other essentials for operating the platform. These shared resources are best calculated by dividing the total overhead by the number of development teams using the platform. For example, in my last platform engineering project, the overhead was about $100 per month per development team. As the number of teams on the platform increases, the infrastructure overhead becomes a smaller part of the total operating costs.
Costs of on-call: This amount depends on the incident management structure and the incentives for the 24/7 support team. The exact amount may vary due to extra pay for bank holidays. Let’s say the on-call rate is $1000/week (source Oncall Compensation for Software Engineers).
The value of internal developer platforms
In monetary terms, the benefits of internal developer platforms are described below.
1. Faster onboarding
From my observations, a typical average for onboarding is two weeks before the developer is able to be fully productive. It's rare that the onboarding process is completely streamlined, and as a result, there are usually multiple service tickets that need to be resolved by different people. The cognitive load and time required to search for resources and guidelines are also notable. The waste of resources during the onboarding process can be significant. An internal developer platform reduces this by an order of magnitude (one day is usually enough).
The average onboarding time is 2 weeks or 80 hours.
At least half of it (40 hours) results in being completely blocked from doing actual work.
Saving 40 hours per new developer equals $1800.
Inefficient onboarding at a company with 30 new developers per year results in a loss of $54,000. An IDP that streamlines the process saves the same amount.
2. Increase developer efficiency
In large organizations, the overhead for getting things done is high. This sometimes makes developers feel like they have to fight to make things happen. This can include requesting access to new tools, creating an additional service account, revoking access when someone leaves the team, waiting while people are on vacation, or when tickets bounce between departments. All of these things can create bottlenecks. Streamlining and optimizing these bottlenecks is a primary goal for platform engineering teams.
Research by companies like Dynatrace indicates that only 40% of a typical engineer’s time is spent on productive tasks. Instead of using this dramatic number, let’s assume something more optimistic (based on my personal observations) for the sake of these calculations:
Assuming a poor developer experience causes developers to waste 20 hours a month (average) that could be spent on productive tasks. This is 240 hours a year, which costs $10,800 per developer.
Efficiency gained by 20% per developer with platform engineering equals 30 hours/month saved, resulting in $16,200/year savings per developer.
3. Shorter infrastructure spin up times
Building production-grade infrastructure involves a thousand little details. The vast majority of developers don’t know what those details are, so when you’re estimating a project, you usually forget about a number of these critical and time-consuming details.
For a production-grade infrastructure based on the Kubernetes ecosystem in a public cloud, it’s at least two months of effort for two experienced engineers. It typically takes:
Setting up cloud landing zones (access control, networking).
Implementing infrastructure as code.
Implementing CI/CD or GitOps workflows.
Setting up observability.
Testing performance, disaster recovery, scalability.
Performing security and compliance audits.
In total, 168 hours/month x 2 months x 2 engineers = 672 hours of engineering time (one-off cost of $30,240 per team). An IDP giving developers fully up-and-running infrastructure transforms this into a saving of the same amount.
However, I have seen many examples of teams taking as long as six months before serving production traffic. This is especially true in less mature organizations without infrastructure blueprints or reference architectures.
4. Reduced infrastructure maintenance costs
It's increasingly common for teams to spend more time managing infrastructure than building new features. In our customer engagements, development teams reported spending between 10% and 40% of their total time managing infrastructure and tooling for their team.
Typical maintenance activities and associated costs:
Ongoing cost optimization efforts (8 hours/month)
Monitoring and troubleshooting the infrastructure, setting up alerting and observability dashboards (24 hours/month).
Keeping up with upstream technology and component changes (32 hours/month).
Performing regular infrastructure release management (24 hours/month).
Troubleshooting, addressing technical debt, refactoring (16 hours/month).
Total monthly cost: 104 hours/month, $4680/month per team, $56,160/year per team. That amount is saved using an IDP to streamline those processes.
5. Reduced integration costs
Integrations tend to be one of the most time-consuming activities, requiring coordination among multiple groups of people. Each team will face this challenge for the first time, and collectively these teams will have to solve the same issues multiple times, compounding the overall cost. Based on How much do integrations cost (and is it worth it)? A standard workflow's estimated cost is between $5,000 and $15,000. For custom integrations, the estimated cost ranges from $20,000 to $100,000+. On average, an IDP creates a one-time saving of $10,000 per team for each integration.
Less direct benefits of internal developer platforms
Here, we’ll have a sideline section for things where I won’t be able to calculate for you as it’s done on a case-by-case basis. However, these things are significant, often being a main driving factor for platform engineering on its own. Explaining this in-depth is beyond the scope of the article.
I think it’s fair to say that without a proper level of governance, people sometimes do crazy things such as storing sensitive data in plaintext or exposing unprotected access to internal systems. Or just when we leave it to individuals, they do something and simply forget. It creates a significant opportunity cost and should be somehow included in the economics of internal developer platforms.
This section is exactly about that.
1. Improved security and compliance
When it comes to security and compliance, development teams typically must take care of:
Addressing non-functional security requirements before going live in production. This includes hardening processes, implementing policies, performing security assessments, or engaging a vendor to conduct pentests.
Measuring the potential risk of a data breach. Based on the Cost of a data breach 2023 | IBM report, the global average cost of a data breach in 2023 was $4.45 million, which shows an increase of 15% over a 3 year period. Each company should assess the potential impact for itself based on the nature of its business.
These are highly subjective numbers specific to your organization. In contrast to doing everything yourself, a centrally managed platform that has been audited and tested for InfoSec requirements means that all applications hosted on it are automatically compliant at a non-functional level. And you only do it once for all teams!
2. Improved business continuity
Apart from the direct costs, service outages create trust and credibility problems. By improving infrastructure reliability companies can avoid the cost of downtime. Atlassian’s article examining the cost of downtime shares some spectacular reports, including a 14-hour outage in March 2019 that cost Facebook an estimated $90 million. The article also identifies a per minute downtime cost that is applicable to businesses outside of tech giants like Facebook:
A more recent report (from Ponemon Institute in 2016) raises Gartner’s average from $5,600 per minute to nearly $9,000 per minute.
This is a significant cost so it should be a feature in your platform engineering calculations. Speaking from my own experience in the retail sector, we were able to save about $120,000 per month with a new deployment platform simply because the infrastructure was stable.
3. Improved time to market
High-performing organizations that have adopted platform engineering practices can see a lead time for changes several times faster than those of low performers (days instead of weeks).
Without a developer platform, the teams would have to:
Integrate and pre-configure deployment tooling
Figure out a way to monitor and troubleshoot
Satisfy infra-level security requirements out-of-the-box
Establish support and incident management processes.
In contrast, teams working with a developer platform can significantly reduce the mean time to production because the platform enables developers to deploy and operate software in a secure, efficient, and reliable manner.
4. Reduced total cost of ownership
Having multiple teams designing, implementing and operating their infrastructure leads to higher costs of ownership. Each team has to run and configure systems themselves. In contrast, a centralized, well-architected environment brings direct cost benefits.
According to insights from KPMG:
Right-sizing instances typically reduce the total cost of ownership by up to 7 percent.
Reducing environments and using auto-scaling can reduce TCO by up to 9 percent.
Capitalizing on favorable pricing models and commitment discounts to improve average cost rates can reduce costs by up to 10-percent.
5. Accelerated migration
Platform engineering helps to lower the costs and impact of migrations. Instead of loosely coordinated, unstructured migration efforts, we have a consistent and transparent approach.
The development teams spend weeks or months migrating in case of vendor change or cloud migrations.
Business case summary
If you’ve been working along through to this point, you should now be ready to put the findings of your ROI calculation into a business case summary, along these lines.
Time to value
This represents the time requirements to build your platform which is capable of onboarding development teams. Establishing additional processes around operational excellence should be also included.
ROI (return per year)
This represents the return on investment in platform engineering.
Net effect per year
This represents the money equivalent after deducting all costs related to building and operating the platform.
How much efficiency gain do you need from the start?
Getting to the next level of efficiency is a long-term game. It always takes time. It's like adding another "nine" to your uptime SLA. I'd advise you to think for yourself and not buy into the idea of another platform MVP in a few weeks. The time to "hello world" is always fast and impressive, but getting something production-ready involves a thousand little details. On the other hand, it doesn't take much effort to see the positive impact of platform engineering early on, even when the platform is not fully finished.
Let’s have a look at two examples of platform engineering efforts that bring value early:
Exploring the problem space in your company. Especially building a better understanding of how developers work, what technologies they use and what patterns emerged among different teams. All these insights are valuable input to your leadership discussion. If you don't know where to start, you can either work with external vendors that offer low-cost, fixed-time platform discovery assessments (for example the company I work for) or consider assessing this by using off-the-shelf products such as DX: Developer Experience Insights Platform which I can personally recommend.
Starting team enablement activities. It’s like running a platform team without the platform product yet. Where platform engineers act more like enablers, helping a single development team pave the way to production while providing valuable feedback for future platform development efforts.
In case you face financial constraints, it’s worth looking into the potential cost savers in this space:
Narrow down the platform scope to a single capability. This could be self-service provisioning of company-compliant and well-integrated Kubernetes clusters. Eventually, expand the team and platform boundary to areas which need attention.
Offer limited SLA which simplifies the architectural requirements and doesn’t require a fully-fledged operations team yet. Instead of providing a highly available architecture, it might be something suitable for struggling teams or low-tier apps serving traffic during business hours as a starting point.
Build gradually on top of Managed IT services or existing infrastructure blueprints in your organization.
Apart from all these positive calculations, it’s worth asking yourself: are there any additional risks of building an internal developer platform that can impact the overall cost? What about measuring the cost of cooperation between various teams, stakeholders and the central platform team?
That’s it for now
Money is a universal language that everyone understands. Now you can use the calculations you've developed to advocate the value of platform engineering within your organization.
Now that you've read this article, I hope you have a more complete view of the platform engineering landscape, its pitfalls and advantages. Everything in the above article is based on my own experience and from my point of view, which is why I want to ask you:
What's your perspective on platform engineering?
Do you have any interesting real-life stories to share?
What new dimensions did you discover while reading?
Feel free to write to me directly or leave a comment here. I will make sure all your comments and questions receive a thorough response. I’m open to writing collabs.
Read previous articles: