Scaling Platform Building: Balancing What is Unique to Your Org and Common Across Teams

In today's fast-paced tech landscape, platform engineering has become a strategic priority for organisations seeking to streamline development, enhance operational efficiency, and maintain a competitive edge. Building an internal platform that serves your organisation’s unique needs is crucial to unlocking faster development cycles and leveraging cloud-native technologies. But how do you design a platform worth building?

In this post, we’ll explore the challenges of only relying on cloud providers for your platform, the core principles of platform engineering, how to treat your platform as a product, and why a Thinnest Viable Platform (TVP) can help you balance innovation with scalability. You’ll learn how to create a platform that accelerates development, maintains alignment with your business goals, and enables efficient, scalable operations.

Identify What is Unique to Your Organization and Common to Your Teams

As with any other technology, it is important to start with understanding the why behind implementing it. A successful internal platform doesn’t just provide tools for developers—it abstracts away complexities while aligning with your organisation's unique business objectives. One of the foundational principles of platform engineering is identifying the right balance between what's unique to your organisation and what's common across teams.

Many teams within the organisation face repetitive challenges such as security configurations, resource provisioning, observability, and deployment workflows. While repetitive, these challenges are also non-differentiating in the industry, as they are needed and provided by all software-building organisations. A well-designed platform standardises these processes, empowering your teams to move faster and focus on delivering value.

Don’t Reinvent the (Platform) Wheel

While your platform should aim to leverage common solutions with consistencies across teams, your company should also leverage common solutions with consistencies across organisations or even the whole industry. When your needs are common within internal teams and across the industry, adopting existing market solutions can be highly effective. Examples include on-demand computing, scalable databases, and dead-letter queue logic. In these cases, an individual organisation can leverage a lot of power by using commodity implementations by cloud providers or other third-party providers.

When determining what can be purchased versus configured vs built bespoke, you may want to consider using a Wardley Map. This technique was introduced in 2005 and has been used across many industries, companies and even different scopes of products from B2B, B2C and more.

A Wardley Mapping template identifies which areas of the map are best suited to third-party providers. These areas are further away from the buyer's value and have progressed further on the path to commodity.

Example: Tailoring Your Platform to Your Industry

HIPAA-compliant infrastructure is an example of a non-negotiable requirement in the healthcare industry. In financial services, strict audit trails and logging protocols are a must to meet PCI DSS compliance.

While public cloud providers like AWS, Azure, and Google Cloud offer general-purpose solutions that enable configuration and management of infrastructure, audit trails and logs, they don’t solve your company's unique compliance policies and processes out of the box. This is where your internal platform steps in, providing custom solutions that address your organisation’s specific needs as determined by your auditors and by your policies while allowing teams to focus on higher-level business functionality.

By centralising these core requirements within your platform, you ensure that teams no longer need to reinvent the wheel, creating greater consistency, security, and scalability.

Build vs Buy vs Blend: Cloud (Alone) is Not Your Platform

Third-party providers like public cloud platforms (AWS, Google Cloud) and Software as a Service (SaaS) tools (GitHub, PlanetScale) offer an array of services designed to meet broad needs—compute, storage, databases, and managed Kubernetes services. These cloud platforms provide scalable, general-purpose tools that organisations can rely on.

However, they often leave gaps in areas like custom compliance configurations, governance models, or tailored developer experiences. Cloud providers and SaaS tools don’t (and won’t) optimise their solutions for your specific organisational workflows or multi-cloud strategies.

On the one hand, the generic and high-leverage solution these tools provide makes them so powerful. They create an economy of scale that has reduced our time and cost to run servers and other core tooling to only small percentages of what it used to cost. And their incentive to adopt more users and more use cases will encourage them to continue to innovate and add more abstractions to their offerings. 

On the other hand, this drive towards economies of scale means that their solutions are destined only to move further away from the specifics that make your business unique. You can see this as an example in the progression in Google Cloud from GKE-hosted Kubernetes to GKE Autopilot, which removes the need to manage the Kubernetes Data Plane nodes. This is immensely powerful for users; however, there will never be a completely auto-configured RBAC for Google Cloud, as that depends on your specific business needs.

The power of industry-wide solutions can also be their limitation. This is where platform engineering comes in—building a customised platform that integrates these services while filling the gaps with bespoke solutions that are tailored to your unique needs.

Platform as a Product: A Shift in Platform Engineering

To build a platform that truly serves your teams, it's essential to realise platforms are not static, one-time projects—they are evolving products that require continuous iteration and improvement. Successful platform engineering in this environment requires a mind-shift change to treat your platform as a product. Product thinking is a growing discipline within all of software engineering, and it has been applied to platforms for quite a long time. However, despite a white paper being released as far back as 2017, the practice continues to struggle when applied to internal products such as platforms.

A timeline portraying some of the most significant milestones in the Platform as a Product movement from 2017 onwards.

After almost a decade of this movement, it has become clear that if you view your platform as a product, the end user—your internal teams—is the customer. Building features and capabilities should be driven by their needs, pain points, and workflows. Regular feedback loops help ensure your platform stays relevant and valuable over time.

Start with Building the Minimum Viable Platform

When designing your platform, it’s tempting to go big. However, a Minimum Viable Platform (MVP) approach is more effective. Start with the minimum set of features that your teams need to begin developing and iterate from there. By starting small, you can get fast feedback, improve upon what works, and avoid bloated, unnecessary features.

This MVP approach is fundamental to successful platform engineering. It allows you to focus on simplifying development processes, abstracting complexity, and enabling self-service models that empower teams to work autonomously.

In addition, MVPs flex the team's muscle to build based on user feedback. When platforms are delivered in a big-bang fashion, the platform engineers do not gain experience in incorporating user feedback. Also, the users themselves are less likely to engage in feedback as they don’t feel they are part of the process.

Move from Minimal to the Thinnest Viable Platform

While the MVP helps avoid early complexity, it is equally important to avoid platform bloat over time. This is where the concept of the Thinnest Viable Platform (TVP), described in the book Team Topologies, comes into play. A TVP focuses on continuously refining and simplifying your platform, ensuring it remains scalable, maintainable, and efficient in the long run.

As your platform grows, it's critical to remove unused features, thereby continuing to push towards higher abstractions and remove custom solutions which can be substituted for commodity options available by 3rd party providers. There have been so many examples of this in the past due to cloud providers from data centres to VMs, from self-hosted Kubernetes on VMs to managed installations, and from self-hosted databases to managed global scale solutions.

A simple diagram shows how an MVP can start small, but its focus on the initial product through to the complete product can encourage its growth over time into something bigger and bigger. While TVP may start similarly small, it will also see aspects of the original solution disappear not only due to learning about product fit but also due to leaning on newly created commodities in the market. This allows the solution to stay lean while continuing to grow in impact at a similar pace.

The most efficient organisations are constantly on the lookout for where their custom solutions are no longer a differentiator and instead are dragging their team down with high maintenance when a commodity service can be substituted from the industry. While this migration can be costly, it is important to step away from the sunk cost fallacy of existing internal tools. The process of doing this not only improved the efficiency of that one solution but, more importantly, improved the team's ability to architect their platform in a way that can reduce this migration cost the next time.

The goal is to keep your platform "thin," meaning it remains minimal but powerful, offering just enough to support your teams while avoiding unnecessary complexity. This will support the multiplier effect of a small platform team supporting a much larger user base instead of watching platform maintenance costs outgrow the value it provides.

Conclusion: Build a Platform That Aligns with Your Business

Incorporating platform engineering principles into your organisation is about more than just technology—it's about creating a foundation that aligns with your business objectives, scales with your growth, and empowers your teams to focus on innovation.

By viewing your platform as a product, starting with an MVP and continuously refining it into a Thinnest Viable Platform, you can ensure that it remains a critical asset in delivering business value. Build your platform around what makes your organisation unique while providing common solutions for your teams, and you’ll see increased efficiency, better developer experiences, and a more scalable operation overall.