# Read the dev.to Sanity integration write-up, how does it apply to a mature codebase?

Asked by Bogdan Ilic on 2025-08-20. Tags: sanity, evaluation, setup.

I went through the [dev.to article on the Sanity integration for A/B testing and personalization](https://dev.to/amorimjuliana/sanity-integration-for-ab-testing-and-content-personalization-da1)
before asking here. It is a clean walkthrough, but it starts from a fresh
project.

Our codebase has three years of Sanity schemas, a custom fetch layer with its
own caching, and GROQ queries scattered across feature folders. Which parts of
the article transfer as-is, and which parts quietly assume you are starting
from zero? I would rather know the real integration surface before pitching
this internally.

## 1 answer

### Accepted answer from nk_ristic (2025-08-21)

Did this on a codebase about your age last quarter, so here is the honest
split.

The setup itself transfers as-is. `npx croct@latest init` works in existing
projects, it does not care how old your Sanity schemas are. The slot fetching
pattern from the article is also unchanged, you fetch a slot where a component
renders and pass default content as the fallback.

Where a mature codebase actually differs, and this surprised me positively:
your custom fetch layer stays. Nothing about the integration wants to replace
how you query Sanity. The GROQ results you already fetch simply become the
fallback passed to the slot fetches, caching and all. We did not touch a
single schema or query, we only added the slot calls next to the components
we wanted to personalize.

The part the article compresses because it starts fresh is deciding which
components to map. With three years of schemas you will not map everything,
and you should not. Adoption is gradual and component-level, no migration
involved, so we started with two high-traffic components, proved the value,
and expanded from there. That is also the shape of the internal pitch that
worked for us: no rewrite, no schema changes, two components to start.