Case study · DTC storefront automation

Two storefronts, 134 custom
modules, one connected lineThe only page here where every number names its source

These are our own brand storefronts, running real orders and real complaints every day. We proved this on ourselves before offering it to anyone else — which is also why we can show you the logs behind each figure below.
Book a diagnosticAll case studies

Custom site modules

134 · 62 + 72

Themes

Both written from scratch

Languages in production

10+

Figures without a source

0

Measured, not projected

Seven numbers, each with the record it came from

A performance figure without a stated source gets read as marketing copy by anyone technical, and they're right to read it that way. So each line below names where it came from.
Content throughputsource: publishing logA long-form article went from 8 hours to 16 minutes, of which 15 minutes is a human final review — what disappeared is the first draft, not the checking.
Content volumesource: article countsOver 100 articles published across the storefronts, in 10 languages, with terminology and policy wording consistent site-wide.
Support automationsource: agent transcripts80%+ of incoming enquiries close without a human. The rest the agent escalates itself — when it can't find an answer it doesn't invent one.
Product imagerysource: image production logOver 100 product images produced, with per-image cost falling from ¥200 outsourced to ¥10.
Image turnaroundsource: our own product launchesA batch of 24 images went from 10 days of waiting on an outside vendor to 0.5 hours — launches are no longer gated on artwork.
Incident detectionsource: monitoring logSite anomalies are flagged within 1 minute on average. Previously found by hand, averaging 24 hours — often after a customer noticed first.
Multilingual syncsource: translation workflowA policy change propagates to 10+ languages within 1 minute. It used to take 5 days, during which the storefronts contradicted each other.

These are our results, not a commitment about yours. Your catalogue, volume and starting point are different, and we won't extrapolate a payback period from someone else's numbers — including our own.

Why this could be wired in at all

We wrote the storefront, so the hooks were there from day one

This is the part that doesn't transfer from a plugin. Both themes were written from scratch, and the automation entry points were built into them before there was any automation — forms that feed a workflow directly, content held as fields rather than hard-coded copy, machine-readable output for AI crawlers, and a direct channel for media and files.

Not a site plus some tools

The usual sequence is: build a storefront, then bolt automation on through whatever integrations exist. That ceiling is set by the integrations. Here the sequence was reversed.

134 modules is the consequence, not the point

62 on one storefront, 72 on the other, counted as theme section files. They exist because specific pre-sale questions kept coming up — each one answers something a buyer asks before ordering.

One knowledge base underneath

Support answers, article drafts and translated policy all resolve against the same source. That's why a policy change reaches ten languages in a minute instead of five days.

The same week

After it was connected, and while it was still by hand

Not how it works internally — just what the week looks like from the inside.

Once it was one line

  • ✓One policy change lands in every language the same minute
  • ✓Support answers come from the same knowledge the articles are written from
  • ✓A launch batch of images is produced as one consistent set
  • ✓Anomalies arrive as alerts, with the likely cause attached

While it was four separate jobs

  • ✕Each storefront updated by hand, in whatever order people got to it
  • ✕Support and content keeping separate, quietly diverging notes
  • ✕Images ordered, chased, re-cropped, waited on
  • ✕Problems reported by customers before anyone internal saw them

When this doesn't apply

Three cases where we'd tell you not to bother

Written down because a case study that fits everybody fits nobody.

Low-ticket, fast-moving consumer goods

Nobody researches a €30 purchase. Selection and trust aren't the bottleneck there — traffic cost is, and this doesn't fix traffic cost.

Marketplace-only sellers

On Amazon or TikTok Shop the page structure isn't yours to control. This whole approach assumes the storefront belongs to you.

Very few, fully standardised SKUs

With three models and a spec sheet you can read at a glance, the entire selection-support problem this solves doesn't exist.

Questions

What people ask about this one

The first is the most common, so it's first.
01Does this approach work for any industry?+

No, and the honest boundary is above: it assumes a considered purchase, a storefront you control, and enough product complexity that buyers have questions before they buy. What does transfer between industries is the shape — one knowledge base feeding support, content and translation — not the specific modules. The diagnostic starts by checking how far your business sits from that shape, and we'll say plainly if it's far.

02These numbers are from your own storefronts. Why should they mean anything to us?+

Because they're checkable, which is rarer than it should be. Each line names the record it came from, so a technical reviewer on your side can ask to see it. What they are not is a forecast for your business — your volume, catalogue and starting point are different. They're evidence the system runs, not a promise about your results.

03Why are there no screenshots?+

Screenshots carry brand names, product categories and real customer data, and they can't be indexed or read aloud. Where structure needs showing, we draw the structure instead. The same rule protects you if you become a case study here.

04Do we have to rebuild our storefront to get any of this?+

No. A single workflow module — support drafting, translation, product content, image production — can be added to a storefront you already have. Building the site ourselves is what let us wire the automation in at the foundations rather than bolt it on, so more is possible that way; it isn't a precondition.

05Will adding a second workflow later cost extra?+

Yes, and it's written into the contract at signing rather than raised mid-project. Day-to-day maintenance — parameters, wording, knowledge entries, keeping up with model and API versions — your own technical people can handle, or you can buy an annual maintenance subscription. A new workflow or a new system integration is new development, scoped and priced as a new project.

Next

The question is which of your weeks looks like the right-hand column

A diagnostic walks your current process and comes back with which steps are worth automating first — and which to leave alone. The fee is credited in full against the project.
Book a diagnosticHow the service works