Every successful digital delivery hides a collection of missteps, tough calls, and “if only we had known” moments. This final article in the series is a candid reflection on the things we hadn’t expected, over-engineered, or curve balls that got thrown in. If you’re preparing to lead a composable implementation, I want to share what we’d do differently not to critique, but to guide. Leadership is not just about what you get right. It’s about how quickly and honestly you learn. 

Not Everything Needs to Be Composable 

This might sound strange in a series about composable architecture, but it’s a truth worth stating: just because you can decouple everything, doesn’t mean you should. 

In one case, we over-segmented the content model in the early sprints. It looked great on paper elegant, clean, modular. We were re-architecting a Content Model that was from a parallel project to not lose out on Velocity. But in practice, it added complexity for authors, created friction in preview workflows, and slowed down localisation. We ended up redesigning the content model specifically with XM Cloud in mind. This was done so successfully, that the customer ended using this as a blueprint for the other parallel project. The lesson? Composability should always serve the user, not just the architect. 

Start With Governance, Not After It 

I’ve said this throughout the series, but it’s worth repeating here. We have seen numerous projects, where agencies let the excitement of building take precedence over the discipline of defining governance. 

The result? Editors had too much access too soon. Translation rules were unclear. Workflow bottlenecks weren’t discovered until UAT. That cost agencies valuable time not just in delivery, but in velocity. 

What we do is, we define roles, workflows, and responsibilities in sprint zero and sprint 1. Not in parallel. Not post-launch. At the start. 

Don’t Assume XM Cloud = XP in the Cloud 

There’s a mental trap that experienced teams fall into: assuming the move to XM Cloud is a lift-and-shift. It’s not. Some familiar features don’t exist. Others work differently.

And others like Sitecore Search unlock entirely new capabilities, but require new thinking. 

We underestimated the change management required for our devs and content teams. What we should have done: a focused enablement phase, not just documentation. Demos. Q&As. Feature parity maps.  

You can Plug in Personalisation Post-Launch but you should do this as part of G-live 

Personalisation should always be on our roadmap ideally as part of phase 1 but on one project, we came in after Go-live as a rescue partner. We saw that the incumbent had delayed the strategy thinking until after go-live. Unfortunately, this mythical phase 2 never came. By then, the content model was fixed, tracking was inconsistent, and the effort required to retrofit the experience was disproportionate. 

In composable builds, personalisation has to be part of your IA. It’s a strategy, not a setting.  

Watch the Frontend Bloat 

Composable platforms give you freedom including freedom to make poor decisions. On one project, our initial frontend framework was over-engineered. Too many unnecessary animations, complex dependencies, performance trade-offs in favour of aesthetics. 

It looked great. But performance suffered. We had to re-optimise core templates. We learned (again) that the best user experience isn’t just about design it’s about speed, accessibility, and stability. 

The biggest learning is to translate how the UI aesthetics would impact Performance and your budget.

The Most Underrated Skill? Editorial Empathy

Perhaps the most powerful lesson was this: the difference between a good and a great implementation isn’t technical. It’s how it feels to use. 

If we had brought content authors into feedback cycles earlier not just to train them, but to listen to them we would have caught usability issues earlier. We would have improved naming conventions. We would have reduced friction.

We now embed authors from sprint one, not just for training but as active contributors to shaping the platform.

Final Thought

Every project leaves you with a list of what you’d do differently. That’s not failure. That’s leadership.

If I could offer two pieces of advice to any Digital or Technology Leader about to undertake their own composable or Website Transformation journey, it’s this:

• Don’t just plan for success. Plan for iteration. Because the projects that succeed most often aren’t the ones that got it right the first time, they’re the ones that were honest enough to admit what needed to change.

• Make sure the UX/UI Designers are not designing in a silo. The Front End team needs to be sitting in and guiding the Designers when an accelerator is being used.

Thank you for following this series. I hope these reflections help you ask better questions, avoid the avoidable, and lead with both ambition and humility.

If you have any questions about how to get started or want to explore what this could look like for your business, feel free to get in touch. I’d be happy to share insights from recent projects and help you map a path forward.