PATTERN NOTE
When your CMS eats your improvement budget.
Most property developer websites are built on platforms whose running cost is so high there's nothing left in the budget to actually improve the product. The platform decision is a product-velocity decision.
Vinay Raja
7 min
There's a quiet pattern inside most developer marketing budgets. The line item for the website CMS – the licence, the hosting, the maintenance retainer, the periodic forced upgrades – has grown over the years to a size that nobody in the marketing team is comfortable defending. It eats roughly the amount of money that the marketing team would otherwise have used to improve the website.
The result is a website that ships once, then stagnates. New features arrive at a rate of one or two a year, and even those usually require a separate funding request because the standing budget is consumed by keeping the existing platform alive.
Why it matters
Three things go wrong when the CMS is eating the improvement budget.
The website never improves. The product that should be the developer's primary digital asset stagnates between rebuild cycles. Every piece of buyer feedback that should drive an iteration ends up in a parking lot for the next rebuild three years away.
The team stops investing in the platform. When the CMS is the source of pain rather than leverage, the marketing team stops asking for things. Innovation moves out of the platform and into one-off tactical channels.
The rebuild cycle compounds the cost. Every three years the developer commissions a major rebuild. The new platform inherits the same problem. The rebuild cost is a recurring cost, not a one-off cost, and it's structurally avoidable.
The platform decision is a product-velocity decision.
How Tydal sees it
The platform decision is one of the highest-leverage moves a developer can make in their digital marketing programme.
Audit the actual cost. Most developers don't know what their CMS is costing them across the full stack. The audit is a cross-functional view of the true total cost of ownership over a five-year window.
Run the platform options against a velocity criterion, not a feature criterion. The criterion that matters is how quickly can the marketing team ship a new feature on this platform without engineering support?
Build the cost-velocity case for the CFO before you build the platform case for IT. Frame the case in financial terms first – the new platform reduces run cost by X, frees up Y for ongoing product investment, and accelerates feature deployment by Z.
Where this shows up in our work
The AVJennings Masterbrand Website. A seven-year-old Sitecore platform was consuming the entire digital marketing improvement budget. We evaluated eight CMS platforms. Modelled three five-year cost scenarios. After the rebuild, on the same retainer envelope, the team is shipping five to six new features a month. Hosting cost dropped from $5K/month to $500/month – a 90% reduction. Feature deployment cycle is six times faster.
What to do about it
If you're a developer or builder thinking about your own platform stack, three places to start:
Calculate your true CMS share. Add up everything: licence, hosting, support retainer, internal IT time, the cost of every tactical workaround. Divide by your total digital marketing budget. If the share is north of 15%, you have a platform conversation to have.
Count the features you've shipped on the website in the last twelve months. Not new pages – features. If the count is in single digits, your platform is consuming your velocity.
Don't wait for the next forced upgrade to have the conversation. Run the audit on your own timeline rather than waiting for the licence renewal to create urgency.