Derby's Craft CMS enquiries tend to arrive in one of two states: an install that's fine but ignored, or one that's actually stopped working with the developer nowhere to be found.
Karl picks these up directly. He's worked in Craft CMS and ExpressionEngine only, since starting Expression 37 in 2007. Nobody else on the team ever touches the work.
Before anything's recommended, he reviews what's genuinely in the install. Depending on what he finds, that's a fix, an upgrade, or an ongoing retainer.
Why do Derby engineering sites end up in worse shape than most?
Because the content keeps growing long after anyone's paying attention to the CMS underneath it. Rolls-Royce's aerospace work and a substantial rail supply chain mean Derby has more manufacturers publishing catalogues, spec sheets, and supplier documentation than a typical city its size, and those libraries expand steadily for years while the Craft install running them gets less and less care. Eventually search stops returning anything useful and nobody can explain why.
Karl fixes that specific problem for Derby businesses, on top of the usual list: neglected plugins, versions several releases behind, sites inherited from a developer who's moved on. The work starts with reading what's actually in the codebase, not a description of the symptoms over the phone.
The install this usually turns out to be:
A manufacturing or engineering site where the document library has outgrown its original structure, and searching it properly stopped working somewhere along the way. Frequently there's a Stripe, Salesforce, or HubSpot connection nobody currently understands, set up by whoever built the site originally. Often the previous developer simply isn't reachable any more. And it's rarely a recent build, most have gone several major versions without a proper compatibility check.
Common questions Derby clients ask:
Where do you even start with a site like that?
By actually reading it. Templates, plugins, however the content's grown over time, all reviewed before a number gets attached to anything, because guessing at scope from a description tends to be wrong in exactly the ways that matter.
Do we need someone local, or is remote genuinely fine?
Genuinely fine. The entire process, from that initial review through to deployment, happens without anyone needing to be on-site, and Derby's an easy trip if a meeting ever turns out to be worth having.
Nobody here really knows how this site works anymore, is that unusual?
Not remotely. It's closer to the default state for a site this size once the person who built it moves on. Sorting what's genuinely custom from a bolted-on plugin just takes someone reading the code properly.
Should the Craft version itself worry us?
Generally, no, not by itself. Sites run fine for years on older releases. What actually causes trouble is whatever's been added on top and left to rot, so that's where an audit spends its time.
What does a standing arrangement actually change day to day?
Someone's watching before a visitor spots a problem, not just reacting once one's reported. Response is faster when it matters. And you're not re-explaining the site to somebody new every single time.
And the cost of all this?
A single job is priced once, upfront, as a fixed number. Anything ongoing runs monthly. Nothing gets agreed until you know exactly what it involves.
Ready to get started?
If your website is business-critical and needs a specialist who will take proper long-term ownership of it, get in touch. Karl will respond personally and give you an honest view of how we can help.
