Why we rebuilt innatus.digital (and what we chose)
After years on WordPress and Elementor, I've rebuilt our own site on Next.js 16 and Sanity v5. Here's why I made the switch, what I prioritised, and what I learned along the way.
Have you ever looked at a web agency's own site and thought it didn't match their client work? The cobbler's children famously have no shoes, and for the past couple of years, our own website has been a perfect example. I've been building client sites on Next.js and Sanity, recommending modern stacks and headless architecture, and meanwhile our own site was running on WordPress with Elementor. It worked. It was fine. But "fine" isn't really the standard we hold client work to, so it was time to practice what we preach.
Why we left WordPress
Let me be clear: there's nothing wrong with WordPress for a lot of use cases. We still recommend it for certain projects, and we still maintain several WordPress sites for clients. But for our own site, WordPress and Elementor were causing friction. It's a relatively small, content-driven marketing site. We want it to be fast, easy to update, and a showcase for how we work.
Elementor generates a lot of inline CSS and JavaScript. Page load times were acceptable but not impressive. The editing experience was clunky for what should have been simple content updates, changing a paragraph meant working through Elementor's builder interface, which is designed for layout work, not content editing. And the gap between what we were building for clients and what our own site ran on was becoming slightly embarrassing.
The decision process
We considered a few options. Staying on WordPress but switching to a headless setup with WPGraphQL was one. Moving to Astro was another, it's excellent for content-heavy sites and would have been a perfectly reasonable choice. But we landed on Next.js 16 with Sanity v5, primarily because it's the stack we know best, it's what we recommend to clients, and rebuilding our own site on it gives us an up-to-date reference project we can point to.
Next.js 16 specifically because of the React 19 form actions (our contact form works without client-side JavaScript), the improved caching model, and Turbopack build speeds. Sanity v5 because the Studio improvements make content editing genuinely pleasant, and the real-time preview lets us see changes as we type.
What we prioritised
Performance was the top priority. Pages load quickly on a typical connection. Server components mean we ship almost no JavaScript to the browser on content pages, the only client-side JavaScript is for interactive elements like the mobile menu and the contact form submission feedback.
Content structure was second. In Sanity, every piece of content is structured, blog posts have proper schemas with categories, excerpts, and rich text bodies. Services are modular. Case studies have defined fields for challenge, approach, and results. This makes the content portable and queryable in ways that Elementor's visual builder never allowed.
Design was deliberately restrained. DM Sans for body text, IBM Plex Mono for code and accents. A single brand blue (#146FF8), near-black for text, warm off-white for backgrounds. No animations for the sake of animations. The design should feel like a studio that values clarity and craft, because that's what we are.
What we learned
Rebuilding your own site is a different experience from building for clients. You're simultaneously the developer, the client, and the project manager, which means scope creep is a constant temptation. We kept ourselves disciplined by defining the scope upfront and treating it like a client project, discovery document, content model, phased delivery. The blog you're reading now was part of phase one. Case studies and more detailed service pages are coming in phase two.
This being a fresh Sanity v5 project meant we could design the schemas from scratch without any legacy, and the new Studio features, particularly conditional fields and the improved validation, meant we could simplify some schemas that previously needed custom components.
Tailwind v4 paired with Next.js 16 is a genuinely excellent developer experience. The build is fast, the output is lean, and the utility-first approach means we spend very little time context-switching between component logic and styling.
Was it worth it?
Absolutely. The site is faster, easier to maintain, and actually represents how we work. If we're going to tell clients that modern headless architecture is worth the investment, you should be able to show them our own site as proof. Now we can.
For the technical details behind this rebuild, see the companion series: How we designed the Sanity schema, Migrating 90 posts from WordPress, Our Tailwind v4 design system, From force-dynamic to on-demand ISR, Structured data and SEO, and Visual editing with the Sanity presentation tool.
If you're thinking about a similar move, whether from WordPress, Squarespace, or any other platform, we'd be happy to talk through what's involved. Drop us a line at [email protected].
Chris Ryan
Managing Director
17+ years in full-stack web development, most of it leading teams agency-side across e-commerce, CMS platforms, and bespoke applications. Specialises in infrastructure, system integration, and data privacy, with hands-on experience as a Data Protection Officer. Founded Innatus Digital in 2020 to offer the kind of honest, technically-led partnership that he felt was missing from the agency world.