Walking Skeletons, Not Prototypes: Rethinking What a Platform POV Should Prove

During a recent proof of value (POV) of Syntasso Kratix Enterprise, one of the participants said something that's stayed with us.

"Maybe [this is] beyond the scope of a pilot, but top of mind are things like upgrading the minimum version of a database, or making a cipher change across S3 buckets, or updating SSL on CloudFront. Something you're changing consistently across large parts of your infrastructure."

They weren't wrong to feel that way. Upgrades are a production concern that touches real systems, requires coordination across teams, and carries actual risk. A two-week evaluation doesn't feel like the right place to go anywhere near them.

The problem is that when a platform evaluation focuses primarily on what is easy to demonstrate in two weeks, it tends to emphasise "Day 1" concerns. But your platform is the heart of your engineering department and, in turn, the heart of your business, so you're making a decision that will support you for many years to come. This decision deserves more input than just the easiest version of the job.

Aim to build walking skeletons, not prototypes

The prototype trap

Many teams come into a POV asking one primary question: Can this thing work?

They set up an environment, build out their main use case, and check whether the platform delivers the features showcased in the polished demo. When the demo runs smoothly and the team leaves energised, the evaluation is declared a success.

But "can this work on Day 1?" is the easiest question any platform will ever have to answer. The real test comes later, when the platform is managing dozens or hundreds of services instead of just a couple, when a security requirement changes and needs to propagate everywhere before fines or breaches occur, when a new team needs to go "off-road" from the idealised platform path.

Those aren't exotic problems. They're what running a platform actually looks like. And a POV that stops short of them may prove the platform can deliver a polished demo, but not necessarily how it behaves under operational pressure.

Walking skeletons, not prototypes

In software engineering, a walking skeleton is a thin, end-to-end implementation. No, they are not feature-complete or production-ready, but they are connected all the way through. The goal isn't to build everything; it is to build just enough to expose where the real complexity lives before you're committed to the architecture.

A POV should work the same way.

Not a polished demo of the best-case scenario, but something that runs the full operational journey end-to-end. Can we provision a service? Yes. But also: what happens when we need to change how all services are provisioned? Can we deploy? Yes. But also: what does the upgrade story look like when we're managing fifty things instead of two?

The skeleton isn't trying to be complete; it is intentionally designed to be just real enough to reveal where the friction is.

For example, a platform team might simulate rotating TLS certificates across every ingress point in a sandbox environment or upgrading a shared PostgreSQL version used by multiple services. The goal is not to execute a production migration during the POV, but to understand how the platform coordinates change, communicates risk, and scales operational work.

Upgrades: the thing you're not testing (but should be)

No one expects a production upgrade during a two-week POV. That's not the argument.

The argument is that there's a lot of ground between "don't run a production upgrade" and "don't look at upgrades at all", which is where many evaluations fall into without realising it.

What you should actually see is an upgrade performed on the platform itself, not just documentation describing the process.

What does upgrading one component look like? Is it a manual checklist or something the platform drives? And what happens when that same operation needs to run across fifty services? Is it fifty times the work, or something the platform handles centrally?

When something goes wrong mid-upgrade, how does the platform tell you? Is there a rollback path, or are you on your own?

Who else needs to be in the loop, including specialists like security and finance or consumers like application teams, and does the platform fit into their workflows or around them?

These aren't just edge cases; they are the operational reality of running a platform at scale. Any product you're seriously evaluating, whether open source or commercial, should be able to demonstrate this in a sandboxed environment. If they can't, that's their answer.

Pushing past the happy path

When you're scoping a POV, it's worth being explicit about which Day 2 scenarios you want to cover. The default agenda will almost always focus on provisioning and deployment. You need to push beyond it.

Ask to walk through an upgrade end-to-end. Push on what changes at scale. Ask what a failed upgrade looks like and how recovery works. Find out which of your teams would need to be involved in a real upgrade and whether the platform actually supports how they work.

These questions can feel adversarial, but they're the questions your team will be wrestling with eighteen months from now, in a planning meeting that's gone long because nobody can agree on how to safely roll out a breaking change. Getting the answers now is just good practice.

Beyond upgrades

The upgrade question is the sharpest version of a more general test: does this platform actually handle operations, or does it just automate provisioning?

The same question arises elsewhere. When a new compliance requirement needs to apply to every service in your catalogue, is that something the platform can drive centrally, or is it a problem that falls to each team individually? 

The operational model matters internally as well. If a database or security team wants to contribute capabilities to the platform, does that process scale cleanly, or does everything funnel back through the original platform team? And for the engineers maintaining the platform itself, is there a reasonable testing story, a local development loop, and a CI pipeline for platform changes?

None of these needs to be fully built out in a POV. But getting a clear picture of how the product approaches them is revealing. Platforms built primarily for demos tend to have confident answers about provisioning but vague answers about upgrades, governance, and operational ownership. Platforms built for operations tend to have opinions about it all.

This is ultimately why platform architecture matters so much: the real challenge is rarely provisioning infrastructure once but evolving it safely over time.

Ask for the things that feel too big

Upgrades felt too big for a POV to our customer. That's probably not unusual. The instinct makes sense as these are production concerns, and a POV is not production.

However, the whole point of a good POV is to surface real concerns early, before the decision is made, when you still have room to change course. After you've committed, discovering you never tested for something tends to be an expensive lesson.

The teams that get the most out of these exercises treat a POV as a real-world stress test. They're not trying to see the best-case scenario; instead, they're trying to find the edges. That means asking for the things that feel too big, too complex, too "we'll figure that out later." Because the things you postpone evaluating today often become the hardest problems to change later.

If you are building a platform, investigating platform orchestrators, or just looking to learn more about platform upgrades, please contact the Syntasso team. You can also learn more about Syntasso Kratix Enterprise (SKE) via our website and SKE docs.