The four phases to Minimum Viable Platform (MVP)

We already discussed why as a platform team you need to start with a Minimum Viable Platform (MVP) to ensure your platform engineering initiative is successful. TL;DR, you want to make sure you can prove value quickly to all your key stakeholders and keep iterating fast,  gaining increasing support and buy-in from the different groups without losing momentum.

In this article, we’ll dive deeper into the four phases of the MVP framework we developed after working with dozens of enterprise organizations (including Fortune 50-sized organizations) to help them deliver their MVP in no time at all.

By the way, if you have any follow-up questions or just want to chat MVPs, you can join the monthly session I host or set up a call with one of our platform architects.

Quick recap: MVP scope

Before I get to the four phases, here’s a quick recap on what an MVP is and isn’t. The technical outcome of the MVP should give you a representative first version of your Internal Developer Platform (IDP), that could quickly be ready to suit the needs of early-adopting pioneer teams. It should represent real requirements focused on the common denominator group of resources that your workloads normally require.

The MVP should be representative, repeatable, iterative, and innovative. It should not be compliant with all your security and policy requirements or involve advanced architectures or configurations.

While reference architectures are the standard for what an enterprise-grade IDP looks like, the MVP focuses on a subset of the reference architecture that encompasses all the key components to ensure it is actually representative and can clearly show value to users (e.g. developers) and other stakeholders (e.g. architects, executives). You will therefore want to have developer interfaces like Score, alongside CI/CD, Infrastructure as Code (IaC), a Platform Orchestrator, and your basic resources (such as common databases, basic compute, and simple networking). 

Now that we are on the same page, let’s dive into the four phases of the MVP framework. There’s an initial discovery phase where we map everything out and align on the key metrics and success criteria we’re working against. Ideally, the whole process is outcome-focused, and we use this phase to understand what those outcomes are and how they align with business objectives and goals. There’s a technical build-out period that includes both the integration and deployment phases. Finally, an adoption phase to plan out scaling the MVP to a full blown IDP. Let’s look at them in detail.

Phase 1: Discovery

Discovery is probably the most important phase.  Get it wrong and everything else you do after won’t be as impactful, both in the short and long term. Interestingly, it’s also the phase that teams have a tendency to try and rush through. So avoid the temptation!

Make sure that you really take the time to ensure your platform initiative is aligned with broader business objectives and that you’ve defined the right scope and boundaries around it. Here’s where you should ask questions like:

• What are the desired outcomes for my MVP?
• What are the business goals that my platform engineering initiative is aligned with?
• How will I measure the success of the MVP?

On the technical side of things, you should cover the following topics:

• What pain points do developers have? What user stories are crucial to improve?
• What pain points do ops and infra teams have?
• Which developer metrics are being tracked? How?

The last question is especially important. A key aspect of your MVP that will determine its impact (and whether it’ll move on to a full-scale IDP rollout later) is how you define metrics to compare what was happening before and after the MVP. Consider questions like:

• Once onboarded, how long until a developer is able to do their first PR?
• How many PRs and tickets do Ops and infra teams receive every month?
• How many DBs exist across all environments? Are they individually described with IaC?

These are only some of the questions you should ask in this phase. We prepared a Discovery Guideline to help you cover both business and technical questions, and define the metrics you’ll measure the MVP against. You can download it here.

Phase 2: Integration

Once you’ve agreed internally on the questions you want to answer and how you’ll measure success, it’s time to get your hands dirty. The integration phase is where you set up your organization within Humanitec, assigning all admin and other roles, while also connecting your cloud providers and Kubernetes clusters. If needed, you’ll also integrate the Agent and Operator.

You can then proceed to create all the resources you defined in phase one, as well as the environment types (non-prod only) you’ll use during the MVP. You can now deploy your first sample application!

Phase 3: Deployment

Now that you’ve wired together the different components, you’ll set your Resource Definitions and resource matching (i.e. the rules for how developers will consume your infrastructure). You will also define your values and secrets , and set up your CI/CD pipeline. Finally, you’ll set up the developer interfaces, Score, and, if required, a portal (e.g. Backstage). You’re now ready for an end-to-end deployment test.

Phase 4: Prep for adoption

Preparing for adoption and scaling to full enterprise-ready IDP is as crucial as the discovery phase. Here’s where you will measure the impact of your MVP on both the developer and the Ops workflows you identified in phase one as well as on your cost baseline.

This is also where you’ll prepare an ROI calculation for a final leadership-level presentation that focuses on the key metrics you identified and measured, together with a forecast of future value creation and an overall IDP roadmap. The latter should be supported by a full-scale security requirements review and a plan for onboarding and training of the first few pioneer teams.

MVP to IDP

The MVP program is the ideal way to move quickly and avoid losing momentum on your platform engineering initiative. It’s designed to let you stress-test all Humanitec products in real-life use cases and settings while ensuring you have a clear framework to prove value to execs and all key stakeholders (including yourself).

If you’re curious about where to get started and could use some support, take a look at our MVP program, or kickstart your platform engineering initiative right away and talk to a platform architect.