Every website build starts with a decision most people never see: what's it going to run on? For this project, we didn't just default to what we know. We tested something new, and we're glad we did.
We sat down with our web development and design team—who lived in this build for almost a year—to walk through why we tried Sanity instead of just sticking with WordPress. Take a deep dive with us into the biggest surprises and what we'd tell a partner weighing the same decision.
Why Try Something New in the First Place?
Page load speed was the first thing that got our attention. Sanity coupled with a frontend framework like Next.js is fast, and that speed has a direct impact on how a user experiences a site. But speed wasn't the only reason to test it. We wanted to see if the platform would be a good fit to integrate with our partners going forward, and the freedom built into the backend interface made the idea of a transition feel a lot less intimidating than expected.
That's the mindset behind most of what we do. We don't chase new tools because they're trendy; we test them because our partners deserve a team that knows what's out there, not just what's comfortable.
First Impressions Inside Sanity
Opening Sanity for the first time felt daunting. Most of our processes are built around plugins in WordPress, and none of that existed here. SEO had to be built from scratch. The flip side of that blank slate is a sandbox to do whatever you want, and once that clicked, the platform stopped feeling intimidating and started feeling like room to create.
The mental model is different too. Instead of thinking in templates and plugins, you're thinking in structure. Schema types work a lot like Advanced Custom Fields, except the developer is the one deciding what those fields even are.
Setup, Hosting, and the Vercel Factor
One of the biggest surprises came from how the site is hosted. The site runs on Vercel (a platform that hosts application servers,) connected directly to a GitHub repository, so pushing updates live is genuinely simple. Vercel handles a lot of what we'd normally manage by hand on WP Engine, including environment variables and the switch from a dev server to the live domain. That efficiency cut our go-live timeline down to a fraction of what a comparable WP Engine build would typically take.
That kind of efficiency matters. It's not about replacing a platform we trust, it's about knowing which tool gets a specific job done faster for the partner in front of us.
Design Freedom Without the Drag and Drop
If you've built a site with Elementor, you know the appeal of drag and drop. Sanity doesn't have that, and we're not going to sugarcoat it. There's no drag and drop editor. What you get instead are simple, structured fields to fill out, and those fields keep the design consistent every single time. It's creative freedom in a different form, building fully custom instead of working inside someone else's template.
That tradeoff ended up being one of the most valuable parts of the whole build. Consistency isn't glamorous, but it's what keeps a brand looking like itself on every single page. It's the same principle behind good internal linking and SEO strategy: the structure behind the scenes is what makes the experience up front feel effortless.
Documentation, Support, and an Unexpected Tool
When we got stuck, we weren't left guessing. The documentation is genuinely strong, backed up by Sanity's Discord channel, Reddit threads, and a direct support form. On top of that, using Sanity’s MCP server made it easy to look at issues within specific document types and schema, which became a real time saver whenever we hit a sticking point.
Content Editing: A Different Kind of Simple
Our favorite part of the whole project was the editor experience which was much simpler than a WordPress dashboard. The sidebar makes it obvious exactly where to go, with no ads and no popups to click through along the way. It's close to idiot-proof (and we mean that as a genuine compliment.)
We believe the Studio is something a partner could use without our team hovering over their shoulder, but an experienced developer still needs to configure it upfront to capture each partners’ specific needs. That part isn't optional.
How It Performed Once It Went Live
The project kicked off in October, moved into full design in March and wrapped in September—more than 150 hours across redesigning the site, transferring data, rewriting copy, condensing pages and building new case studies. Once the site was live, the difference was noticeable right away.
But the best part isn't how we launched it—it's what our team can do with it now. Anyone on-staff can log into the new site and update a page live, no developer required. We can set permissions so each team member only touches the content that's theirs to touch, and reusable design elements keep every new page consistent without having to rebuild it from scratch.
Version Control Changed How the Team Worked
This might be one of the most underrated parts of the whole switch. Real version control means multiple people can work on different pieces of the site at the same time and merge everything into one final version without stepping on each other's work. That kind of simultaneous collaboration is genuinely difficult to pull off inside Elementor.
So, Which One Would We Recommend?
Here's where we want to be honest with you: this isn't about one platform beating the other.
It depends on the partner's needs. If a business is going to be heavily building out its own landing pages and new designs on a regular basis without a developer on standby, WordPress and Elementor are still the right call. That's exactly what makes WordPress such a strong fit for so many of the businesses we build for. But for a partner who wants something fully custom and already has development support in place, a framework like Next.js, Astro, or React paired with Sanity opens up a different level of freedom.
Would we use Sanity again? Without hesitation. The most time consuming part of this build was constructing each individual section from scratch. Next time around, the plan is to have a library of custom-built sections ready to go, so future builds are less about starting from zero and more about assembling the right pieces for that partner's goals.
The Takeaway
Testing Sanity didn't happen because WordPress let us down. Instead, it happened because we wanted to know what else is out there before a partner ever asks us the question. That's the standard we hold ourselves to on every build.
If you're trying to figure out which platform actually fits your business, our web development team is eager to have a conversation. No pressure. No jargon. Just an honest answer based on what you actually need.
