In Part 1, I wrote about migrating our websites from Contentful and Sanity to Payload CMS, the challenges of delivering it against a hard deadline, and my experience of feeding the AI Vampire. There’s more to the story than the migration itself. Particularly what it’s enabled us to do, where the bottlenecks have moved, and how it’s changing our ways of working.
I’m also still dealing with some of the consequences of feeding the AI Vampire. Some good, some less so, and a few things I’m trying to get better at.
“Simply going faster isn’t enough. You need to adapt how you drive.”
The bottleneck has moved
One of the things I’ve enjoyed most about this experience is how it’s changed my thinking about what our engineering team can achieve, and where the constraints now sit. The migration has saved us around $40,000 a year in Contentful fees alone, more when you consider overages and the increasing costs associated with additional content models and languages.
But there were other costs too. Contentful’s restrictions influenced how we solved problems, and we accumulated technical debt as a result. To be fair to Contentful, some of that was down to decisions we made early on. Our content modelling was overdue a refactor. We’ve also avoided the agency fees we’d previously priced up for the migration. Which is a shame, as I was looking forward to working with Joe & Toby from evensix.
Self-hosting Payload isn’t free, but the ROI is compelling. Particularly when you consider the flexibility it’s given us and how quickly we can now make changes.
It’s that flexibility that excites me most.
The feedback from our article writers has been particularly encouraging. They’re enjoying Payload, and the page previews and simpler image management alone are already saving them time and effort. We’ve also been able to improve the articles themselves. Writer profile pages, social links, sharing, breadcrumbs, article categories, author pills on comments and improvements to the comments experience. A collection of relatively small changes that together make a meaningful difference. And it’s not just articles. Our branded “Sell With Us” pages are now fully customisable, while FAQs and legal documents are far easier for the business to manage. These are text-heavy pages, some with legal requirements, where being able to preview changes and use a WYSIWYG editor is particularly valuable. We’ve also moved our PDF generation logic out of the main frontend and into Payload, removing libraries and dependencies from an already busy codebase.
Now we’re looking at banners, statistics and more site configuration. Giving the business greater control over the site without needing engineering to get involved in every change. There’s plenty still to refine, but we’re already changing how the business uses the CMS, and when it uses it Previously, some of our technical constraints dictated how we approached content and changes to the site. Now we have more options. Rather than working around the CMS, we can adapt it to better support how the business actually wants to work.
Thanks to our investment in our delivery platform, deploying software is fast and dependable. We can release frequently, with the confidence that we can roll back when needed. Though we have yet to test a rollback in anger (fingers crossed). The bigger constraints are increasingly elsewhere. We have more than twice as many stakeholders with ideas and requirements as we have engineers. That’s not a bad thing, but it makes prioritisation, capturing requirements and deciding what not to do increasingly important.
And then there’s code reviews…
Getting clear requirements from the business. Breaking work into sensible pieces. Reviewing PRs. Making sure we’re solving the right problems rather than simply producing more code. It reminds me of Andy Grove’s High Output Management. It’s a tech management cliché, but his thinking about constraints and bottlenecks is as relevant now as when it was written. Fix one bottleneck and you’ll often expose another.
It’s a bit like racing. Find more speed through one corner and you can carry that speed into the next. Finding your braking point changed and you need to reconsider your line, and the balance of the car feels different. What worked before doesn’t necessarily work at the higher speed.
Simply going faster isn’t enough. You need to adapt how you drive.
Engineering systems are much the same.
AI has given us considerably more speed, but that speed changes the demands on everything around it. Generating code faster is fantastic, but it doesn’t automatically mean we’re delivering more value. If anything, it makes clear requirements, sensible architecture, effective code reviews, good testing and observability even more important.
Our ability to produce code has improved enormously. But if we can’t review it, validate it and get it into production without creating congestion elsewhere, we’re simply moving the bottleneck. And the environment isn’t standing still. The tools, models and techniques are constantly improving, which means our engineering systems need to keep evolving too.
4D Chess
One of the areas I’ve been experimenting with is how we manage this increased flow of code. Worktrees and stacked PRs are giving us more options, almost like playing 4D chess with the work in progress. Rather than being blocked waiting for a PR review, we can continue working on related changes, break work into smaller pieces, and have multiple agents running concurrently in the same repository, sometimes managed by different engineers. Done well, these approaches give us a framework for managing that concurrency without a huge context-switching cost. Done badly, there’s enormous potential to make a complete mess.
It’s part of a wider shift we’re exploring. Not simply generating more code or releasing for the sake of it, but creating the conditions where small, well-tested changes can move reliably through the system. That means better requirements, manageable PRs, effective reviews, automation, observability and the confidence to release and roll back when needed. We’ve made a lot of progress, but there’s always more to improve.
How we’re using Cursor, Claude Code, worktrees and stacked PRs to support that is something I want to explore in a Part 3.
A better place to build from
One thing I deliberately didn’t do during the migration was try to make everything perfect Much of our original content modelling reflected the constraints of Contentful rather than how we’d ideally structure things in Payload. Trying to redesign everything while migrating against a hard deadline would have introduced unnecessary risk. Instead, I prioritised moving the content in a repeatable way, getting it working, and preserving the ability to iterate afterwards.
Now I’m in clean-up mode. Removing Contentful IDs, gently refactoring collections to make them easier for the business to use, and exploring more of what Payload has to offer. I’ve also come away with a long list of ideas and improvements. Some are relatively small, others could change how we use the CMS across the business.
I’ve even found myself noodling on new site features during Sidequest Saturdays. What has surprised me is how much I want to keep building. I thought I’d finish the migration, tidy things up and move on. Instead, I keep finding more things Payload could help us do, both for the business and in how we work as an engineering team. It’s genuinely fun, and I’m loving working with Payload.
After a difficult couple of years with Contentful, I feel liberated. For the first time in a long time, it feels like we’ve got a CMS we can build on rather than work around. There is a little sadness about not continuing with Sanity . I’ve enjoyed following its development over the years, and I still think it’s an impressive product.
But one of the things I particularly like about Payload is how open it is and how straightforwardly it stores our data. If Sanity, or something else, offers a compelling ROI in the future, moving again should be considerably easier.
That’s not something I could confidently say about our experience with Contentful.
I wish Contentful and Salesforce well. We’re still a Salesforce customer, although I have to admit I don’t entirely understand the rationale behind their acquisition.
Still finding the balance
The migration is finished, but I’m not sure the wider changes it has set in motion are.
Personally, I’ve come away feeling closer to the team and the challenges they’re facing, with a long list of things I’d like to improve, both in our codebase and how we work. Getting properly back on the tools has reminded me just how much I enjoy building. It’s also given me a much better view of the friction the team experiences day to day, and the opportunity to address some of it directly.
But I’ve definitely fed the AI Vampire a little too much. During the more stressful parts of the migration, I let building take priority over some of my management responsibilities. The deadline was real, but so was the temptation to keep going when I was enjoying making progress.
I’m grateful for the team’s patience. I’m now trying to be more deliberate about balancing making and managing. Part of that is delegation and automation, increasingly through GrokBot, which is taking on more of my repeatable tasks. Part of it is being stricter about when I’m available to the team and when I’m making time to build.
I’ve always enjoyed early mornings. A coffee, a quiet house, and some uninterrupted time to code or write is a lovely way to start the day. I’m trying to make better use of those quieter hours for focused work, while keeping the rest of my day available for the team and the responsibilities that come with leading engineering.
And, importantly, getting some of my boundaries (and sleep) back. I don’t want to retreat from the code again. Staying technically involved is helping me better understand what the team are experiencing, and I hope it’s making me a better engineering leader.
Equally, I don’t want my enthusiasm for building things to come at the expense of the team or my other responsibilities. There’s plenty still to figure out. In how I work, how we manage the increased pace of development, and how we continue adapting our engineering systems as the tools improve.
More speed is brilliant. But only if we can make good use of it.
I’d be interested to hear from anyone who’s made a similar CMS move, particularly from Contentful to Payload or Sanity. What would you do differently?
And for those of you leading engineering teams, how are you balancing staying on the tools with the demands of leadership? Have you found yourselves feeding the AI Vampire too?
One thought on “Is the Vampire Juice worth the squeeze: A CMS Migration [Part 2]”