BLOGPlatform Engineering

7 Platform Design principles that drive a successful Developer Platform

To have maximum impact, the right teams need to have the right control and responsibilities in place and make it easy to do the right thing

Platform Engineering
Time to read
7 minutes
May 17, 2024
Jon Shanks

This blog highlights seven crucial platform design principles that frequently get missed. The intense focus on technology can sometimes overshadow broader strategic goals. Before diving into specific principles that organisations should consider, let's explore why internal developer platforms (IDPs) are becoming increasingly vital to organisations in 2024.

Key Takeaways

Developer platforms remove friction for developers, making them more productive

Product teams need to be empowered by platforms to take control of costs to impact their gross margin.

Utilising Cloud best practices will reduce the amount of engineering the platform team has to do and provide better scale and reliability.

Developer velocity, improved productivity and reduced operational costs are all important and motivating factors for any software business. With an average of 28.7 million developers in the world and a worldwide developer salary range from $68.19k to $77.1k, the overall global market spend on Developers is between 1.96 and 2.21 trillion dollars a year.  

According to a survey conducted by the New Stack and Tidelift back in 2019, only 32% of developers' time is spent on writing new code or improving existing code, 35% is spent on managing code including maintenance and testing and 23% on managing operational tasks, meetings and other. Similarly in a survey performed back in 2021 on 250k developers across the world called Global Code Time Report only 52 minutes per day, 4 hours and 21 minutes per week is spent on active coding. 

The findings have found that most companies are bogging down engineers with inefficiencies, slow builds and bad tools. This results in 1.33 to 1.50 trillion dollars of developer inefficiency costs globally. 

To avoid adding to that statistic each year, companies must optimise their development processes. They should provide a platform that not only smooths out daily obstacles for developers but also offers product teams the accountability needed to reduce costs and manage infrastructure more effectively. 


What exactly are platform design principles?

Platform design principles define and outline the expectations of the platform and what value it is looking to deliver long-term to the business, the developers and the wider stakeholders. 

Principles offer a way of challenging how something should be approached when it gets to the implementation detail. They help the platform team keep aligned when features are being worked on with a clear view of the platform direction. 

The principles

Here are the principles that the platform team should follow:

  1. Product teams have cost autonomy
  2. Minimal impact on services
  3. Self-service with guardrails
  4. Standardise with cloud patterns
  5. Product teams control platform changes
  6. Have an API contract
  7. Driven by needs and traction

1. Product teams have cost autonomy

For a product to be deemed successful, it must not only turn a profit but also deliver a healthy gross margin to the organisation. Product teams being empowered to directly control their operational costs should be a key part of any mature developer platform.

A platform should offer clear visibility into how much things are costing and allow teams to reduce costs by:

  • Deleting unused infrastructure
  • Downscaling during off-peak times, especially in non-production environments
  • Right-sizing instances to match the demand and application requirements
  • Using more cost-effective infrastructure

If a platform introduces cost complexity or a lack of control, it will inhibit the autonomy of the team to drive cost-saving techniques on the running infrastructure supporting their applications. 

2. Minimal impact on services

One of the recommended best practices for cloud computing is to use isolated cloud accounts, subscriptions or projects. This approach ensures that workloads, data, environments and services are segregated. Separating workloads into their product teams, business units or similar reduces security risks and the impact on change. 

Consider an application experiencing a surge in traffic, this spike should not affect the performance of other applications. Similarly, applications with differing risk profiles or scalability requirements should not impact each other's security or financial footprint.

Adopting isolated environments helps mitigate these issues, leading to a more robust and efficient way for teams to operate their services.

3. Self-service with guardrails

Developer self-service streamlines infrastructure management, environment management, application deployments, and third-party integrations, boosting efficiency. The objective is to enable developers to deliver features and software more effectively.

Making self-service components secure by default means that Developers can focus on delivery without having to up skill or worry about the security details. 

Allowing Developers to utilise platform capabilities whilst enforcing security checks throughout the self-service experience maintains a healthy security stance without compromising on speed or quality. 

4. Standardise with Cloud patterns

Cloud providers enable repeatability and standardisation when it comes to cloud service consumption and application hosting. These architectures, known as landing zones and well-architected frameworks reduce the amount of engineering required in the platform. 

Some of the cloud capabilities that can be leveraged are as follows:

  • Networking hub-and-spoke models to enable interconnectivity between applications
  • Central Identity and access management with single-sign-on integration
  • Central security policies and methods of grouping and managing policies
  • Central audit services
  • Central billing, cost controls, alerts and visibility management

Engineering effort can be spent on making these patterns a repeatable and automated part of the developer experience. This means development teams will have everything that they operationally need by default, with the scale and reliability of the Cloud. 

5. Product teams control platform changes

Product teams should be empowered to manage operational changes to their cloud infrastructure, with the ability to implement approved updates at times that are most convenient for their end users and during off-peak periods. 

This can be in the form of security patches, moving to the latest version of libraries, upgrading the cloud resource their applications depend on or applying platform improvements associated with their workload infrastructure.  

Releases of new components, configuration changes or amendments to existing versions of self-service artefacts should have gone through rigorous testing phases that validate the security, configuration and upgrade paths. These changes should then be pushed out so development teams can take accountability for applying and testing them as part of their application lifecycle.

6. Have an API Contract

To provide a service that can be relied on, there has to be an API contract in place that gives teams a way of testing and validating their changes before applying them. 

When Developers consume self-service components they must meet the requirements and adhere to the API specification. If specific required or optional configurations differ between environments, then these can be tested and validated through the application lifecycle appropriately. 

Changes to self-service components should result in new versions that attempt to maintain full backward compatibility without causing any breaking changes. This approach will provide teams with a way to test, iterate, and deploy to production without depending on additional resources or specialist skills in their team. 

7. Driven by needs and traction

A Developer Platform, like any product, should be driven by its users, meet expectations and provide value. 

Developers need to be involved in shaping features of the product and validate the ways of working that help optimise their experience. They should be involved in prioritising the roadmap and providing constant feedback to help improve the platform. 

Developer adoption of the platform is a key measure of success. Traction will increase if it is meeting the needs of the Developers. Mandating a platform, however, doesn’t provide a good insight into how easy the platform is to adopt and whether it is enabling Developers in the right way. 


These platform principles are meant to be a guideline to help challenge whether the features meet the ambitions of the business. Engineering the platform against these principles will promote the right ways of working across teams and provide a standard and consistent approach to software delivery in the cloud. 

There are endless ways of solving technical challenges, however, we often see platforms that don't empower product teams or provide them with the right level of developer experience to make their jobs frictionless and easy.

If you abstract too much away, then you run the risk of making your product teams dependent on skilled resources and less able to take ownership and accountability of their services.

It is important for teams to not only focus on common industry tools and capabilities such as CI/CD, code management, monitoring and alike but to also understand the Cloud's well-architected frameworks, landing zone services and how you should be architecting for scale and reliability. 

If you want to learn more about how Appvia has solved these challenges with our product, please visit the feature list of Wayfinder

Related Posts

Related Resources