6 min read · IT & Web Services
Most website problems we're called in to fix aren't really design problems — they're decisions made two or three years earlier that quietly became liabilities. Before recommending a rebuild, we walk every client through the same five questions.
1. Are you fighting the platform, or the content?
A slow, dated-looking site is often blamed on the platform when the real issue is years of unstructured content. We audit content first — sometimes a rebuild isn't needed at all, just a proper information architecture pass.
2. Who actually updates the site day to day?
The best CMS is the one your team will actually use. We've replaced technically excellent systems simply because nobody in the client's office could confidently publish a page without calling a developer.
3. What's the real cost of downtime?
For a brochure site, occasional downtime is an inconvenience. For a site tied to bookings, payments or lead capture, it's lost revenue — and that changes how much hosting and monitoring investment is justified.
4. Does the system need to talk to anything else?
Integrations with accounting software, booking systems or internal tools are the single biggest source of scope creep we see. Mapping these up front avoids a rebuild that's technically finished but practically unusable.
5. What's the three-year plan, not just the launch plan?
We ask clients where the organisation expects to be in three years, because a platform sized for today's traffic and content volume can become the next rebuild if growth isn't accounted for.
A rebuild should solve a problem you can name. If you can't name it clearly, it's usually a content or process issue dressed up as a technology one.
If you're weighing up a refresh versus a full rebuild, our IT & Web Services division can run this audit against your current site before you commit to either.
