How to build a Minimum Viable Platform (MVP)

With the immense growth of platform engineering in the last few years, major analyst involvement, and platform-themed events ever-increasing in size, it’s clear that platform engineering is here to stay. For many organizations, the question is no longer, “Should we build a platform?” It’s now “How do we get started?” The answer is simple: build a Minimum Viable Platform (MVP).

Start small and build fast with an MVP

The main reason to build an MVP is because when starting their Internal Developer Platform (IDP) journey, most businesses fall into the trap of trying to solve all their problems at once. This quickly devolves into what I like to call “complexity quicksand” as the project scope (and risks) increase exponentially. Even worse, some companies mistake platform engineering as being all about tools and spend months figuring out which tool should go where rather than actually building something useful.

Your platform engineering initiative doesn’t need to be a massive transformation, and it shouldn’t require any long, drawn-out planning or approval process. It can start small, nimble, and most of all — cheap. The MVP approach we have built allows you to do exactly that, and has come from experience putting down the roots of platform engineering in a lot of organizations. You can build a simple platform with a pioneer team. You then learn from the process, iterate, and expand out. When following the framework correctly, this enables you to build a platform in just four weeks rather than 40.

How to get started in four weeks 

The MVP concept is rooted in a lean methodology of starting small and simple to prove value and then using feedback to effectively expand over time. Just like  Matthew Skelton and Manuel Pais highlighted in their book Team Topologies, a platform as a product mindset is the key to effective platform engineering.

The reality is that IDPs involve cultural and organizational challenges that many teams do not yet know how to adequately handle. This leads to challenges in planning, designing, building, and then rolling out – it makes it difficult for teams to communicate the platform value not only to leadership, but also to potential platform users.

This lack of clarity can either stop a platform engineering initiative from ever getting started, or result in a prolonged platform engineering process that knocks confidence in the concept.

The MVP framework cuts directly through these issues. By using a fast-moving pioneer team to quickly prove value with a representative use case, you can demonstrate value to key stakeholders and build a clear iterative roadmap for platform growth. This removes funding complexity and simplifies getting both attention and resources for your platform, leaving you to focus on expansion and innovation.

Simply put, all you need to do is:

• Identify a pioneering team that can lead the way when it comes to driving innovation
• Build a highly simplified, representative first version of the platform in the context of a “HelloWorld” scenario
• Develop a product-like roadmap based on user feedback for iteration and growth
• Seek out the influential stakeholders who can drive adoption
• Get said stakeholders onboard quickly and maintain excitement
• Avoid having to win over every single developer team or adjacent team immediately 

We’ve used this process dozens of times to help companies of all sizes (including at-scale enterprises) effectively and rapidly build and expand IDPs.

Building your MVP HelloWorld app

It’s important to remember that the MVP is a representative case for your platform. It should have as much in common with your estate of real apps as possible, so it’s best to avoid complicated or unique cases. Your HelloWorld app should focus on the most common denominator of infrastructure your apps typically use.

Your HelloWorld app should be:

1. Representative: The MVP should have representative basic resources and components that are common across the technical estate. Generally, this includes clusters, containers, version control, a single database type, basic DNS, and basic CI/CD.

2. Repeatable: The basic skeleton created in the MVP process should be able to be used as a “quick start” for other applications and teams within an organization. The MVP is the foundation from which the full-scale platform is built.

3. Iterative: MVPs focus on the future. The context of creating this version of the platform is with growth and iteration in mind. Remember that commitment is required to scale.

4. Innovative: The teams that work on these MVPs are pioneers and drive new ideas forward. MVPs should inspire contributors to learn new things and engage with new technologies. 

At this stage, your MVP should not involve:

1. High compliance scenarios: You can think about security and high-compliance requirements, but an MVP shouldn’t have to comply with high compliance standards.

2. Advanced architectures: Service meshes, multi-cluster deployments, failover, customized portal integrations, advanced CI/CD (Blue/Green), etc., do not need to be covered by an MVP.

3. Advanced resource configuration: You should pick one common resource type to begin with and not try to cover every possible developer request.

4. Advanced observability: Integration of advanced components and highly complex observability services is something you can build on top of later.

Following these principles, your MVP should easily be possible within four weeks. Rather than a timeline of months or years that many platform initiatives have inevitably fallen into. Below is how each week looks for the companies we’ve helped as part of our MVP program.

Week 1: Design your platform

Define goals and outcomes, including ideal end-to-end dev flows. Identify a sample application, design your MVP V1.0 architecture.

Week 2: Integrate your setup

Set up your environments 
and connect them to your infrastructure components (clusters, resources, networking).

Week 3: Deploy your app

Configure your workloads. Implement your end-to-end flow and deploy your sample application.

Week 4: Demo time

Showcase to stakeholders, proving value on both DevEx
and DevOps metrics. Plan to scale to the next teams.

Final outcome:

Standardized golden paths and dynamic configuration to be used as the foundation of your new platform engineering efforts.

Expanding your MVP to an enterprise-grade Internal Developer Platform

By the end of this four-week cycle, you should have an MVP that proves its worth to more than just the developer and platform teams. It should also be ready to grow in a scalable and sustainable way into an enterprise-grade IDP.

Getting stakeholder buy-in will allow you to widen the net of users to gain feedback, enabling you to iterate and expand the scope of your MVP. As more teams see the value, getting funding for a larger platform engineering initiative becomes much easier.

This creates a clear path from a simple MVP to an IDP, enabling Dynamic Configuration Management and standardization by design, which are the primary drivers of DevEx improvement and velocity gains expected from platform engineering.

Get expert guidance with the Humanitec MVP program

We’ve successfully executed this four-week process dozens of times to help enterprises launch their platform engineering initiative quickly and effectively, and deliver value within weeks rather than months or years. The Humanitec MVP program is the best way to get started in a timely and cost-effective way, combined with expert help and guidance from some of the industry's best, most experienced platform architects.

Ready to get started and build your MVP in just four weeks? Contact one of our platform architects to learn more.