Five questions that tell you whether you have a foundation or a front

Can your team launch in a new market or channel without waiting on development?

The symptom is familiar: a market opportunity, a new channel requirement, or a campaign that needs to go live in a format the platform was not built for. The team raises it. A developer estimates the work. It lands in a sprint queue. Six weeks pass. The symptom is timeline slippage. The diagnosis is extensibility. A platform built on a structured content model separates what content says from how it is displayed, which means new channels and markets draw from the same foundation without requiring custom builds each time. A platform built the other way, content tightly coupled to a single front-end, treats every new requirement as a new project. The question is not whether your team is fast enough. It is whether the architecture lets them move at all.

Are you using the platform you are paying for, or a fraction of it?

Enterprise CMS licences are not cheap. The average enterprise spends more than €400,000 a year on martech (Storyblok integration study, 2024, n=300), and a large part of that spend sits in systems whose full capability is never reached. The gap between what a platform can do and what a team actually uses is rarely about training. It is usually structural: the platform was never configured to serve the people running it, so they stopped using it fully and routed around it. If your team is working in spreadsheets, running approvals over email, or maintaining content outside the CMS, the platform has already lost their confidence. Adoption is a lagging indicator of whether the system was built for the people who use it every day.

Do your teams work inside the system, or around it?

Workarounds are quiet and cumulative. No single decision creates them. A team that cannot make a change without raising a ticket finds a way. A team that cannot personalise content without a developer builds a parallel process. Over time, the unofficial system becomes the real system, and the platform becomes an expensive formality. 68% of enterprises migrated their platform in the past three years (State of CMS 2024, n=1,719), and half are already trying another (State of CMS 2025, n=1,300). Many of those second moves answer a system the team quietly stopped using, not a technical failure. The workarounds your team has built are not a sign of resourcefulness. They are a signal about the platform.

If the people who built it left tomorrow, could a new team take it over?

Key-person dependency is a governance problem before it is a staffing problem. When the architecture, the integration logic, or the content model lives in the heads of the people who built it rather than in documented, transferable structure, the platform's real cost is invisible until someone leaves. Maintainability is a design property, not a documentation task. A platform built on clear content modelling, explicit governance, and clean separation between layers can be handed over. One built on institutional knowledge and undocumented workarounds cannot. The question is whether the platform could survive the people who built it walking out the door.

When something breaks, is it a contained fix?

Blast radius is a design choice. In a well-structured platform, a change to one component does not cascade unpredictably into others. A content update does not break a downstream integration. A front-end change does not corrupt structured data. When something goes wrong, the scope is knowable and the fix is targeted. In a platform built without that separation, every change carries risk, and demonstrating control to a compliance team becomes difficult because control was never designed in. This matters most in regulated environments, where the ability to show governance on demand is not optional. The question is whether your platform was built to contain failure, or to propagate it.

What the answers tell you

None of these questions require opening the code. They are observable from how your team works today. If the answers are uncomfortable, the problem is not the symptoms, the queues, the workarounds, the key-person risk. The problem is the foundation those symptoms are pointing at. A platform built to carry the business answers all five cleanly. One that was built for launch, and nothing beyond it, does not.

The gap between a foundation and a front is cheap to identify now. It becomes expensive the first time the business asks for something the build was never designed to give. Answering these five questions from experience is a starting point. Knowing where your platform actually scores is the next one.

You've answered the five from your gut. The Content Platform Intelligence Check scores where your platform actually stands.