A practical, low-risk path from today's Gambio setup to a custom-built operational layer — without losing a single Google ranking, customer review, or marketplace listing along the way.
Don't decide today whether to replace Gambio. Build a custom operational Portal first — the admin tool that fixes article loading, AI content, image processing, and multi-channel publishing — and run it against Gambio's existing REST API. That delivers most of the daily-workflow value in roughly three months at minimal risk. After living with the Portal for a quarter, you'll have evidence rather than predictions about whether Gambio's customer-facing storefront is genuinely a ceiling on the business. If yes, we already have a designed and costed migration path. If no, you save four months of work and stay on a stable foundation.
The current architecture is a stable Gambio core attached to roughly fifteen specialised SaaS products. Most of those are not "Gambio things" — they're independent services we'd keep regardless of what runs the storefront.
Do we really need to replace Gambio — or does an operational portal solve the actual problem?
A defensible read of the platform's strengths and weaknesses for a high-AOV jewellery brand in 2026.
Average order value is high. Customers spend serious time on each product page. The storefront has to do work that a commodity shop's never does.
Eight things a pearls customer expects on a product page:
Gambio's stock storefront delivers maybe four of those eight well. A custom storefront delivers all eight. That's the actual gap — and the actual upside — under discussion.
Not "build vs don't build." The choice is how far we go — and if we leave Gambio, whether we own the storefront or rent it.
Commit to Path 1 now. Defer the Path 2 / Path 3 decision by three months. After running daily operations through the Portal for a quarter, we will know — with evidence, not speculation — whether Gambio's storefront is the real ceiling on the business. If it is, we choose between owning a custom build (Path 2) or leveraging Shopify's platform (Path 3) based on what the data and the team's appetite say at that point.
Two numbers per path: what we pay during the build, and what we pay every month after launch. Claude Cowork at the top-tier Max plan ($200/mo, x20) is our build team and our ongoing dev capacity.
All amounts in EUR per month. Common services (Lexoffice, Magnalister, Shopvote, IT-Rechtskanzlei, PayJoe) are required under every path and bundled at the bottom.
Path 2 is cheapest because there is no platform licence and no Shopify subscription. Path 1 is most expensive because the Gambio licence, Antagus hosting, and Gambio-specific bridge plugins compound over time. Path 3 sits between them — predictable Shopify monthly cost in exchange for less infrastructure ownership.
Cowork is the engineering capacity; it isn't the CEO. Strategic decisions, brand voice, pearl-grading expertise, customer service, legal and tax sign-off, and operations all stay on our plate. What the numbers above show is the cash cost. Our time and attention are real and required at every step — what we save is external dev billing, not effort.
If we go custom (Path 2) instead of Shopify (Path 3), what are we replacing — and what can't we replace? Honest itemisation.
One-tap checkout for customers who've shopped at any Shopify store. Small revenue effect for a first-time-buyer-heavy mix, but real.
No on-call rotation, no dependency-update cycles, no "the server fell over at 3am" risk. Part of what Shopify's monthly fee buys is peace of mind.
Gift cards, subscriptions, B2B wholesale, loyalty programs — Shopify ships these. In custom, each one is its own project the day we need it.
Shopify also charges us for capabilities we'd never use: subscription billing engine, multi-store, B2B wholesale tier, point-of-sale integration, 30+ payment gateways including ones with zero DACH share. Shopify is right-sized for the "average" Shopify shop — not for our specific shape of operation. A custom build only carries what we use.
Given our profile — established multi-country shop, premium positioning, first-time-buyer-heavy mix, no subscription or wholesale needs — the gap between Path 2 and Path 3 on delivered value is smaller than the €1,500 platform-cost differential suggests. Neither is wrong. Choose on the team's appetite for ownership vs leverage, not on cash.
A self-contained operational layer that talks to Gambio via its REST API today, and graduates to talking to a custom shop later — without changing what the team sees.
Upload a Gaura Pearls export, map columns, validate (GTIN, weight, customs code, required fields). Valid rows become drafts. Invalid rows surface in a fix-it inbox. The manual copy-and-paste step disappears completely.
Generate descriptions and SEO metadata from product attributes using brand-tone templates. DE long copy, short copy, EN translations, page title, meta description, JSON-LD. Always review before publish. Every prompt and output is logged.
Drop raw photos in. Multi-size output (master, product, listing, thumbnail). Optional white-background removal. Watermark on master. Filename convention enforced. Final images pushed to Gambio's media API automatically.
One button publishes to Gambio plus Magnalister marketplaces plus Pinterest, with per-channel overrides. Optional competitor scrape — including JavaScript-rendered sites like christ.de — surfaces a recommended price band before you set the price.
Google Business reviews, Shopvote rating history and seal, Merchant Center product feed performance, marketplace listings on Otto and Amazon — all live on other people's servers. They are unaffected by anything we do to gaurapearls.com.
Invoice numbering continues gaplessly or has a clean documented break. The Gambio database is archived read-only for ten years of GoBD retention. The Steuerberater signs off the updated Verfahrensdokumentation before code is written. None of this changes between the three paths — Lexoffice (directly, or via its Shopify app) carries the legal load in every scenario.
Lexoffice, Magnalister, Shopvote, IT-Rechtskanzlei, PayPal, Amazon Pay, DHL, PayJoe, Easyinvoice, GTM, Merchant, Pinterest, AdCell, Google Business — every one of them is independent of Gambio. The Portal sits beside them today; the new shop, if we build it, slots in beside them tomorrow.
Three honest assessments: connecting to Amazon's marketplace directly, connecting to Otto's marketplace directly, and trusting Cloudflare with our customer data. Each has its own rules, its own certifications, and its own split of legal responsibility.
Selling Partner API replaced the legacy MWS in 2021. Direct connection is allowed but heavily regulated — Amazon's policies are stricter than any other marketplace.
Otto's marketplace API exists but is materially less mature than Amazon's. German-only, fewer community libraries, less documentation, and tighter onboarding.
If the new site or Portal runs on Cloudflare infrastructure (Workers, Pages, R2, KV), here is exactly what they cover.
Cloudflare is one of the most heavily-certified cloud providers in the world. As a customer running on their platform, we benefit from their certifications and contractual data-processing commitments.
Yes, partially — and there is no way around it under GDPR. Under EU data protection law, we are the Data Controller and Cloudflare is the Data Processor. The Controller carries the primary legal duty toward our customers (the data subjects). If a Cloudflare breach exposes our customers' data:
• Cloudflare must notify us within ~24–72 hours. They are contractually liable to us per their DPA, subject to the liability cap in the Main Agreement.
• We must notify the data protection authority within 72 hours of becoming aware of the breach (DSGVO Art. 33).
• We must notify affected customers if the breach poses a high risk to their rights (DSGVO Art. 34).
• Our customers can sue us directly (DSGVO Art. 82 — right to compensation). We can then seek recourse against Cloudflare under their DPA, but limited by their liability cap.
This is not specific to Cloudflare — exactly the same legal split applies with AWS, Google Cloud, Azure, Hetzner, any other processor. The only mitigations available are: (1) choosing certified processors (Cloudflare is among the strongest), (2) signing a robust DPA and SCCs, (3) carrying cyber-insurance to cover the gap between provider-cap liability and our potential exposure, (4) minimising the data we actually route through processors (the Portal-first architecture already favours this — most PII lives in Lexoffice + our own DB, not in Cloudflare).
What this means practically for our architecture decisions: the choice of cloud provider does not change our underlying liability profile. It changes the likelihood of a breach and the strength of the contractual fallback. Both favour Cloudflare. But we cannot delegate Data Controller responsibility to anyone — that stays with us regardless.
The "today" list unblocks Stage A within the same week. The "later" list waits until we're approaching the month-3 evaluation.