Making Turtle’s Product Operations Scalable

Before contacting us, they had already consulted another agency. The proposed solution was to introduce Airtable as a separate product management layer to reduce complexity and improve scalability. However, this would have added another system to an already fragmented workflow and came with many drawback that made switching between the systems a requirement if you wanted full control of how products were displayed.

Consequently, they searched for other tools, one of them being Medusa. They had heard good things about Medusa and that we were the people to contact. With this in mind, they contacted us to discuss if Medusa was a good fit for the challenges they were facing with handling their product catalog.

“It is everything behind the scenes related to our product catalog… it is so cumbersome to create products that expanding our product range is happening far too slowly… we would like an API connection to our two key suppliers… and all products must be live-synchronized between the website and HubSpot.”

What initially appeared to be a CMS limitation was, in reality, a structural problem:

• Overcomplicated product schema
• Manual, repetitive workflows
• No streamlined supplier integration
• No real-time system synchronization

The temptation was to introduce a new tool. But the underlying issue was also architectural, not just technological.

This technical landscape mapping revealed a critical insight: the bottleneck was not Sanity itself, but how it had been implemented. The complexity stemmed largely from the product schema. Each product existed as separate language-specific documents, meaning every product had to be created and updated more than once. Even minor changes became repetitive and time-consuming, significantly slowing the expansion of the catalog. This structure also introduced data integrity issues. Fields that should remain identical across languages, such as the available variants and other system-level identifiers, were duplicated across documents. Because these lived independently, they could be inconsistently entered, overwritten, or mismatched between language versions. Over time, this led to “dirty” data and synchronization risks across systems.

The previously proposed introduction of Airtable or Medusa would have added a parallel product database. From an architectural standpoint, this meant splitting the product domain across systems, increasing synchronization complexity, and creating ambiguity around the system of record. While it might have simplified certain editorial tasks in the short term, it would also have introduced new integration overhead and technical complexity for the employees that had to use it in their day to day work. Adding a new tool would have required retraining teams, redefining ownership, and introducing new daily workflows in an already strained setup. Instead of reducing complexity, it risked redistributing it and introducing even more technical ambiguity for non-tech content editors.

Our evaluation showed that Sanity already had the capabilities required to support scale, as long as it was restructured correctly. Because Sanity is API-first, real-time by design, and extendable via frameworks like App SDK, it also allowed us to build proper interfaces for supplier integrations and establish reliable synchronization with HubSpot, without introducing an additional tool for content editors. This ensured a single interface and a single source of truth while still supporting dynamic data flows across platforms.

The strategic conclusion was clear: the client did not need another tool. They needed clearer architecture, better data modeling, and workflows in interfaces that aligned with how their teams actually operated. By staying within Sanity, rebuilding the foundation, and enabling their AI features, we enabled scalability without increasing system complexity for non-tech content editors.

The client was on board with this strategy so our focus could now be on the tangible deliverables that would solve the challenges.

Talking with the stakeholders, we came to realise that this should not only be a sync layer, but also a search layer for the content editors to easily figure out what products they have available and make creating the product in Sanity Studio easy. The Sync Service solution consisted of the following services:

• A Postgres database to store all product data in a normalized format as well as raw data.
• A Typesense search index to enable a consumer-grade search experience with facet filters
• A BullMQ Worker to handle sync jobs consisting of full catalog syncs, and periodic product/stock syncs.
• An API service that communicates with the custom Sanity App SDK interface and enables searching as well as creating products with supplier data.

By using an Adapter pattern for the different Supplier API implementations, we were able to separate the sync job logic and the supplier API specifics, which makes it much easier for us to add a new supplier to the mix. By normalizing all supplier product schemas, we made the schema mapping between Supplier API product and Sanity Product more consistent and easier to manage.

The sync service runs scheduled cron jobs that keep the database in sync with supplier data. When changes are detected to active Sanity products, we send a Slack notification to the client with an overview of the changes and draft the changes in the studio for them to review. This makes sure that no external change or error affects the website, but still makes the process more effective and proactive. This whole setup runs for under 10$ a month on Railway.

The biggest problem the Turtle team faced was creating or updating products in relation to new releases/collaborations, expanding the product catalogue, and changing merchandise trends. Adding 10 new products would require one individual to spend their whole day going through the ingestion process. The flows below visualise each manual action that individual had to go through for each product:

We estimate it to be over 200+ steps just for adding one product in the Sanity Studio and context switching to other sites like their supplier extranet platform or the image background removal software. This does NOT include the product’s variants. Each product could have 10 different color variants, each requiring about 2-5 pictures and 5 variant level fields. This might sound like a lot of steps already, but we are just getting started. Architectural decisions regarding localization further multiplied the complexity.

Because the project used the Document Internationalization plugin, each product document referenced both its own product information as well as language specific information like the description, specifications, SEO fields etc.

This essentially meant that much of the product info had to be duplicated for each language they served, including fields that did not need to be localized like external IDs or flags. This was the culprit for the “dirty“ data, as content editors sometimes forgot to update all related language documents at the same time or forewent the non-critical languages when creating the product. This also meant more manual steps to translate. All in all, a restructuring was needed before doing anything else.

A whole days of work was now possible in mere minutes.