Why a WordPress Agency Chose Sanity + Next.js for a SaaS Landing Page (And Why We’d Still Pick WordPress for E-Commerce)

We’re The WP Clan. We’ve been building, scaling, and maintaining WordPress sites for over a decade. WordPress is in our name, in our DNA, and in about 95% of the projects we deliver.

So when we launched a new product last week — HeyCaly, an AI-powered WhatsApp customer re-engagement platform — and decided not to build its marketing site with WordPress, a few eyebrows went up. Including our own.

This post is our honest, technical breakdown of why we made that call, what the experience was like, and — just as importantly — why we’d absolutely, unequivocally still choose WordPress + WooCommerce for our e-commerce clients.

No drama. No “WordPress is dead” clickbait. Just a real decision, made by a real WordPress team, with real tradeoffs.

Table of Contents

1. What HeyCaly Is
2. The 9-Language Problem
3. Why We Chose Sanity + Next.js
4. The Technical Architecture
5. Why We’d Still Choose WordPress + WooCommerce for E-Commerce
6. The Stoneline Case: Why Sanity Would Be the Wrong Choice
7. Decision Framework: When to Use What
8. What We Learned

What HeyCaly Is

HeyCaly is a SaaS product we built in-house. It helps service businesses — hair salons, wellness clinics, gyms, spas, veterinary clinics, dental practices — fill empty appointment slots using AI-generated WhatsApp conversations.

The platform analyzes a business’s calendar, identifies customers who haven’t visited recently, and sends them personalized WhatsApp messages that feel human. Not template spam. Actual conversations that reference the customer’s last visit, their stylist’s name, their dog’s weight — whatever context makes the message feel real.

The product itself is a full-stack Next.js application with Supabase, Clerk, Stripe, and a bunch of integrations. But the marketing site — the landing page, pricing, about, contact, blog — that’s what this article is about. If you’re interested in the full technical architecture behind HeyCaly’s SaaS platform, check out our detailed tech stack breakdown.

The 9-Language Problem

HeyCaly targets service businesses globally. Not just Turkey and the US — but Spain, Germany, Brazil, Italy, the Middle East, France, and Azerbaijan. We needed the marketing site in 9 languages:

1. English
2. Turkish
3. Spanish
4. German
5. Portuguese
6. Italian
7. Arabic (RTL)
8. French
9. Azerbaijani

With WordPress, multilingual options are:

WPML — The Industry Standard

WPML is the go-to for WordPress multilingual sites, and we’ve used it extensively. At 2-3 languages, it works well. At 9 languages with independent publishing workflows, things get complicated:

• String translation management becomes a part-time job
• Every plugin update risks breaking translation connections
• The icl_translations table grows massive
• Translation memory helps but doesn’t eliminate manual overhead

Polylang / TranslatePress

Solid alternatives with different tradeoffs. Polylang is lighter than WPML and plays well with custom post types, but its string translation interface gets unwieldy at 9 languages. TranslatePress offers a beautiful visual translation editor — you translate directly on the frontend — but it stores translations in a custom table and adds a performance hit from on-the-fly string replacement. Both share the same fundamental limitation: they’re bolting multilingual onto a system that wasn’t designed for it from the ground up.

Weglot — The SaaS Approach

Weglot is compelling because it’s entirely external — no WordPress plugin conflicts, no database bloat, translations managed via their dashboard or API. It auto-translates content and serves localized versions via subdirectories or subdomains.

The catch? Pricing scales with word count and languages. At 9 languages with a marketing site that includes pricing pages, FAQs, blog posts, and legal pages, the costs add up quickly — especially for a lean product team. Weglot makes perfect sense for 2-3 languages on a content-heavy site where the auto-translation quality is acceptable. At 9 languages where every word needs to feel native (our WhatsApp mockup conversations reference local names, local clinics, culturally appropriate scenarios), the auto-translate-then-fix workflow adds more overhead than it saves.

Clonable — The Full-Site Duplication Model

Clonable takes a radically different approach: it creates a translated clone of your entire site on a subdomain or subfolder, proxying the original. You don’t touch your WordPress installation at all. The translated version lives on Clonable’s infrastructure.

For a quick multilingual deployment, it’s remarkably fast — you can have a translated site running in hours, not days. But for our use case, several issues emerged:

• Content control: Clonable proxies your site and applies translations on top. If your original site changes layout or structure, the translations can drift or break.
• SEO ownership: The translated content lives on Clonable’s proxy layer. While they handle hreflang tags and serve proper HTML, you’re dependent on their infrastructure for your multilingual SEO.
• Deep customization: Our WhatsApp mockup with localized names (Ayşe instead of Sarah, Pamuk instead of Buddy), culturally adapted testimonials (Dr. Günay M. from Bakı instead of Dr. Ayşe K. from Istanbul), and locale-specific content variations — this level of per-language customization goes beyond what a proxy-based translation layer is designed for.

Clonable is excellent for businesses that need “good enough” multilingual fast. We needed “pixel-perfect localization” across 9 languages with full content independence per locale.

WordPress Multisite

Nine separate WordPress installations. Nine sets of plugin updates. Nine wp-admin dashboards. We’ve managed multisite networks for clients and it works — but for a lean product team that wants to move fast, the overhead is significant. Each language adds a multiplicative maintenance cost: security patches × 9, plugin updates × 9, theme customizations × 9.

The WordPress Multilingual Verdict

“The real cost of multilingual WordPress isn’t the plugin license. It’s the ongoing maintenance burden that compounds with every language you add.” — Our internal project retrospective

Here’s how the WordPress multilingual options compare at our scale:

We estimated that maintaining a 9-language WordPress site with any of these approaches would require approximately 4-8 hours per month of translation management, plugin compatibility testing, and content synchronization. For a team shipping product features, that’s time we couldn’t afford.

Why We Chose Sanity + Next.js

We evaluated four headless CMS options:

Why Sanity Won

Document-level internationalization. This was the deciding factor.

Sanity’s @sanity/document-internationalization plugin creates completely separate documents per language. The Turkish homepage is its own document. The German FAQ items are their own documents. They share no database rows, no linked meta fields, no fragile translation relationships.

Compare this to WPML’s approach where translations are linked WordPress posts with icl_translations metadata. We’ve seen those links break during migrations, during bulk updates, sometimes during routine plugin updates. Sanity’s approach eliminates this entire class of bugs.

The page builder pattern was the second factor. In Sanity, you define content blocks as typed objects — hero sections, pricing tables, FAQ accordions, testimonial carousels — and compose pages by arranging these blocks. Content editors drag and drop blocks to build pages, similar to Gutenberg, but the underlying data is clean, structured JSON rather than serialized HTML in a database column.

Each block is a strongly-typed object. No shortcodes to parse. No serialized data in a wp_postmeta longtext column. No “what happens when Kadence updates and changes the block format” anxiety. The data is clean JSON, queryable, and completely decoupled from how it’s rendered.

Sanity’s query language, GROQ (Graph-Relational Object Queries), lets you fetch exactly the data you need in a single readable query — resolving references, filtering by language, and projecting nested fields. No multiple database joins, no N+1 query problems, no custom SQL.

The Technical Architecture

Here’s what we ended up with:

Content Layer: Sanity CMS

• Plan: Free (more than enough for a marketing site)
• 17 schema types (documents + objects)
• 155+ documents across 9 languages
• Sanity Studio for content management (runs at localhost:3333 during development)
• Schema deployed to Sanity cloud via npx sanity schema deploy

Frontend: Next.js 16 on Vercel

• Framework: Next.js 16.2 (App Router)
• Styling: Tailwind CSS v4
• Rendering: Server-side rendering (SSR) — every request fetches fresh content from Sanity
• Routing: /[locale]/ pattern with 9 locale prefixes
• Components: 12 page builder blocks, each mapping to a Sanity schema type

Hosting & Infrastructure

• Hosting: Vercel (Hobby plan)
• DNS: Cloudflare (existing — just changed A records from Hostinger to Vercel)
• SSL: Vercel automatic provisioning
• Images: Local /public/images/ directory served via Vercel CDN

Why We’d Still Choose WordPress + WooCommerce for E-Commerce

Here’s where we need to be crystal clear: the HeyCaly decision was specific to a SaaS marketing site. If we were building an e-commerce store, our answer would be completely different.

WooCommerce powers approximately 36% of all online stores. That’s not inertia — it’s because the ecosystem is genuinely unmatched for e-commerce:

1. Product Management at Scale

WooCommerce handles complex product catalogs natively:

• Simple products, variable products, grouped products, external/affiliate products
• Product attributes, categories, tags with hierarchical taxonomy
• Stock management with warehouse-level granularity
• Bulk editing via WP-Admin or CSV import

In Sanity, you’d need to build all of this from scratch. There’s no “product” schema type built in. No cart. No checkout. No order management. No stock tracking. You’re starting from zero.

2. The Plugin Ecosystem

The WooCommerce plugin ecosystem is a competitive moat that no headless CMS can replicate:

• Payment gateways: 100+ options (Stripe, PayPal, iyzico, local bank integrations)
• Shipping: Integration with DHL, FedEx, UPS, local carriers, real-time rate calculation
• Tax: Automatic tax calculation for 100+ countries via TaxJar or native WooCommerce Tax
• Subscriptions: WooCommerce Subscriptions for recurring payments
• Memberships, bookings, auctions, multi-vendor — all available as plugins

Building equivalent functionality on a headless stack means either:

• Writing custom code for each feature (expensive, time-consuming)
• Integrating multiple SaaS services (Stripe, Shippo, TaxJar separately — more moving parts, more points of failure)

3. ERP Integration

This is where WooCommerce truly shines for B2B and enterprise e-commerce. We’ve built integrations between WooCommerce and major ERP systems:

• Exact Online — real-time stock sync, order flow, invoice generation
• SAP Business One — product catalog sync, pricing tiers, customer groups
• Microsoft Dynamics 365 — order management, CRM integration
• Custom ERP APIs — webhook-based bidirectional sync

These integrations rely on WooCommerce’s well-documented webhook system, its REST API (which mirrors the product/order data model exactly), and mature plugins like WP ERP and custom middleware solutions.

In a headless CMS + custom frontend setup, ERP integration means:

• Building custom API endpoints for every data flow
• Implementing your own order state machine
• Handling payment webhook processing manually
• Managing stock reservation logic without WooCommerce’s built-in locking mechanisms

We know this because we’ve evaluated it. Multiple times. The development cost to replicate WooCommerce’s ERP integration capabilities in a headless stack typically exceeds 6-12 months of developer time.

4. Multilingual E-Commerce

Here’s an ironic twist: while we moved HeyCaly away from WordPress partly because of multilingual complexity, WPML actually handles multilingual e-commerce better than any headless alternative.

WPML’s WooCommerce Multilingual plugin provides:

• Per-language product translations with shared SKUs
• Multi-currency support with automatic exchange rates
• Translated checkout flows, emails, and invoices
• Language-specific shipping zones and tax rules
• Integration with the WooCommerce REST API for headless frontends

Try implementing multilingual product catalogs with region-specific availability rules in a Sanity + Next.js stack. It’s a significant engineering effort.

The Stoneline Case: Why Sanity Would Be the Wrong Choice

To make this concrete, let’s talk about one of our active e-commerce projects: Stoneline.

Stoneline is a premium natural stone importer and distributor, serving the architecture, interior design, and construction industries. They offer marble, granite, travertine, and terrazzo collections (under the Palezzo brand) — sourced globally and distributed from Istanbul. Here’s the scope:

Why WordPress + WooCommerce (Catalog Mode) Is the Right Choice Here

Stock reservation. When an architect selects a specific marble slab for a project, that slab needs to be reserved in the ERP system for the duration of the quote process. If the quote isn’t confirmed within the reservation window, the slab is released back to available inventory. WooCommerce’s session and order management system, combined with custom ERP hooks, handles this reservation logic. In a headless setup, you’d need to build a custom stock reservation microservice with TTL-based locks, webhook callbacks to the ERP on quote expiration, and race condition handling for concurrent reservations on the same slab. That’s a significant engineering effort for something WooCommerce’s architecture supports natively.

Regional catalog management. Stoneline operates WooCommerce in catalog mode — no cart, no checkout, no public pricing. Instead, the product catalog serves as a digital showroom where architects and designers browse collections, view slab dimensions and technical specs, and submit quote requests. Different regions see different product availability: a marble variety quarried in Turkey might be readily available for the domestic market but shown as “contact for availability” in the EU catalog. WooCommerce with WPML handles this regional catalog variation natively, while the ERP controls which products are visible and available per region.

B2B wholesale. Stoneline sells both B2C (direct to architects and homeowners) and B2B (wholesale to construction companies, distributors, and fabricators). WooCommerce plugins like B2BKing or custom role-based pricing provide this without building a separate system.

“For Stoneline, the question isn’t whether WordPress is the best technology. It’s whether any other stack can replicate what WooCommerce in catalog mode + WPML + ERP integration gives us — a multilingual digital showroom with real-time stock visibility across 6 languages and multiple regions — without 10x the development effort.” — Our internal architecture decision document

Decision Framework: When to Use What

After living with both stacks, here’s our honest decision matrix:

Choose Sanity + Next.js When:

• ✅ Marketing site, landing page, or product brochure (not e-commerce)
• ✅ 4+ languages with independent publishing workflows
• ✅ Performance is a competitive differentiator
• ✅ Content structure is complex (page builders, nested blocks, cross-references)
• ✅ Development team is comfortable with React/TypeScript
• ✅ Lean stack with generous free tiers
• ✅ You want clean separation between content and presentation

Choose WordPress + WooCommerce When:

• ✅ E-commerce with product catalog, cart, checkout
• ✅ ERP/CRM integration required (stock sync, order flow, invoicing)
• ✅ Plugin ecosystem matters (payments, shipping, tax, subscriptions)
• ✅ Content team is non-technical and knows WordPress
• ✅ 1-3 languages (WPML handles this well)
• ✅ Client needs to self-manage without developer involvement
• ✅ Rapid prototyping — WordPress is still the fastest from zero to live

Choose WordPress + Headless Frontend When:

• ✅ You need WooCommerce’s backend but want a modern frontend
• ✅ Performance requirements exceed what traditional WordPress delivers
• ✅ The development team can maintain two systems
• ✅ Team can handle the additional complexity

This hybrid approach — WordPress as the backend, React/Next.js as the frontend — is increasingly popular and something we’ve written about extensively.

What We Learned

1. The Right Tool Depends on the Job, Not the Trend

Headless CMS is having a moment. Twitter/X is full of developers declaring WordPress dead and singing the praises of Sanity, Contentful, and similar platforms. Our experience confirms that headless is genuinely better for certain use cases — but it’s catastrophically worse for others.

A SaaS landing page in 9 languages? Sanity shines.

An e-commerce store with 80K SKUs and ERP integration? WordPress + WooCommerce, no contest.

2. Multilingual Is the Key Differentiator

If you’re building a monolingual site, the CMS choice matters less. WordPress, Sanity, Contentful — they’ll all get you there. It’s when you add 4+ languages that the architectural differences become deal-breakers.

Sanity’s document-level i18n is fundamentally superior to WPML’s linked-post model for high-language-count projects. But WPML’s WooCommerce integration (multi-currency, translated checkout, localized invoices) is something no headless CMS can touch.

3. Developer Experience Is Not User Experience

Sanity Studio is powerful and flexible. It’s also unfamiliar to anyone who’s spent years in wp-admin. The content team’s comfort matters. We could build the most architecturally elegant system in the world, and it’s worthless if the people managing content every day hate using it.

For HeyCaly, the content team is us — developers. We’re fine with Sanity Studio. For Stoneline, the content team includes non-technical staff who’ve used WordPress for years. Asking them to switch to Sanity would create friction that no performance benchmark justifies.

Where HeyCaly Stands Now

As of today, HeyCaly runs on:

• 9 languages, each with fully localized content including culturally appropriate names in WhatsApp demo conversations (Turkish users see “Ayşe” and “Ahmet”, not “Sarah” and “Alex”)
• Sanity CMS managing 155+ documents with a page builder pattern
• Next.js on Vercel with automatic SSL and global edge delivery
• Zero WordPress dependencies — even the images are served locally from Vercel’s CDN

We purchased the domain a week ago, built the entire site locally with Sanity, and we’ll be pushing it live within the next few days. The speed of going from concept to production was remarkable — and honestly, a significant portion of that speed came from AI-assisted development, which is a topic for another post.

WordPress got us to where we are. It’s still the foundation of our business. But knowing when to reach for a different tool — and having the confidence to actually do it — that’s what separates a WordPress agency from a web solutions company.

HeyCaly is an AI-powered customer re-engagement platform that fills empty appointment slots via WhatsApp. Built by The WP Clan.

Have a project that needs multilingual architecture? Whether it’s WordPress, Sanity, or a hybrid approach, we’d love to hear about it.