E-commerce platform · multi-tenant SaaS
A multi-store e-commerce platform: storefront, payments, email, analytics and server-side conversion tracking run as one system — no stitched-together toolkit of separate SaaS products.
TL;DR — what's different
Situation
A first-time seller hits the same wall every time: before a store can even open, it already needs several separate tools — the platform itself, conversion tracking, email, an abandoned-cart sequence and payments. Each comes with its own account, its own data store and its own technical setup, which a beginner often can't do alone. A typical platform leaves that work to the seller.
Solution
Vantemo is built as a single multi-tenant system. Every store holds isolated data, but all of them run on the same core — the API, the admin dashboard, payments and background jobs. Conversion tracking to Meta, TikTok and Google Ads runs server-side with deduplication, so the seller never has to install pixels manually. Store pages are assembled with a visual editor, and content is built from day one for search and for fast Core Web Vitals scores.
Result
The result is a working platform where a new store launches without stitching together separate integrations: payments are configured, the catalog is loaded, pages are assembled, and server-side tracking and email automation run from day one. The product is currently being prepared for public launch. The portfolio shows the architecture and the capabilities already built; sales figures will be measured in the real market after launch.
Narrative
01 / PREMISE
Vantemo's starting question was broader than one store: how do you make any store launchable quickly, without technical setup. A first-time seller typically assembles a toolkit — platform, tracking, email, payments — and wires each one in separately. Vantemo replaces that toolkit with a single core: what's normally split across several SaaS subscriptions runs here as one system.
02 / ISOLATION
Every store on the platform has its own data — products, orders, customers — and never sees another store's. Isolation is enforced at the database layer: every query is automatically scoped to its store, so there's no separate "don't forget to check" step left to the developer. All stores run on the same core, so launching a new one means configuring it, not building it from scratch.
03 / EDITOR
Store pages — home, category, campaign — are assembled with a visual editor from ready-made components. The seller changes content and structure themselves, without a developer, and the components are already tuned for speed and search. The same editor also builds quizzes: a shopper answers a few questions, and matching products are recommended based on the answers.
04 / PAYMENTS
The checkout flow joins the two payment habits that matter to Baltic buyers: cards via Stripe and direct Baltic bank-transfer links via MakeCommerce. Every store has its own payout account, so money goes straight to the seller. To the buyer it reads as a single flow, regardless of which payment method they pick.
05 / BACKGROUND
Email, the abandoned-cart sequence, SMS, invoice PDFs and ad-data syncing all run in a separate process, in queues. The store stays fast because the heavy work happens in the background and, when needed, retries. Every store has its own email-sending configuration, so one store's volume doesn't affect another's deliverability.
06 / SPEED
Stores are served server-side, with search-ready content, structured data and hreflang across multiple languages. Speed and accessibility scores are checked automatically before every change ships — if a page slows down or its Lighthouse score drops, the change doesn't go through. That keeps speed intact over time, not just on launch day.
07 / AGENTS
The whole admin API is condensed into a small AI toolset — catalog, orders, analytics, content, settings. That makes it possible to run a store by talking to it: "add this product," "show me last week's revenue," "change the order status." The same toolset serves both the assistant inside the dashboard and an external AI agent — Claude Desktop, ChatGPT or Cursor — connecting through an MCP server.
08 / BOUNDARIES
The hard part is letting an AI agent operate inside one store and never touch another. Every connection uses an API key tied to a single store; the store identifier is always taken from the key, never from whatever the agent sends, so a spoofed identifier changes nothing. Keys can be scoped — read-only, or limited to certain areas — and request rate is capped.
Tracking
Browser-based tracking loses part of its purchase signal after iOS's privacy changes and ad blockers. Vantemo sends signals to ad platforms from the server, with deduplication and additional matching — for every store, without manual pixel installation.
Meta
Conversions API · dedup · advanced matching
TikTok
Events API
Google Ads
Enhanced Conversions
Consent
Consent Mode v2
Click IDs
gclid · gbraid · wbraid · fbclid · ttclid
Browser analytics
GA4 · PostHog
The seller connects their accounts; the platform handles pixel installation, matching and event delivery itself.
Tech stack
The core is an API and a shared database that every store runs on. The front ends are built with Next.js, and background jobs run in a separate process with queues. Store data is isolated at the database layer, so one store never sees another's. The whole system is laid out as a monorepo with shared libraries and type-checking from the interface down to the database.
| Front-end | Next.js 16 · React 19 · Tailwind |
| API | Node.js · Hono · TypeScript · Zod |
| DB | PostgreSQL · Prisma (200+ models) |
| Background jobs | BullMQ · Redis · Sharp |
| Payments | Stripe Connect · MakeCommerce |
| Email / SMS | AWS SES · SMTP relay · Twilio |
| AI | Claude · Gemini (Vercel AI SDK) |
| Auth | Session-based · Argon2 |
| Infrastructure | Coolify (Docker) · Cloudflare · Sentry |
| Quality | Lighthouse CI · Playwright · Biome · Turborepo |
AI / Automation
AI is built into the platform through a single model-provider layer: the same tasks run against Claude, GPT or Gemini, with the best-fit model picked for each by price and quality. In the dashboard, the assistant drafts product descriptions, search-ready titles and meta descriptions (up to 60 and 160 characters), blog posts, review replies and image alt text. The same layer translates content between languages. Usage is measured in tokens (units of AI-processed text), with its own rate limit, and a seller can connect their own model key.
Challenges
01
In a multi-store system, the biggest risk is one store's data ending up inside another's. Isolation is built into the database layer and covered by tests, so the boundary holds automatically on every query, rather than relying on a developer's vigilance.
02
After iOS's privacy changes and ad blockers, browser-based tracking loses part of its signal. The fix is server-side delivery with deduplication, so ad platforms get a fuller picture of purchases and the same event is never counted twice.
03
Stores need to differ in look and content while running on the same core. The visual editor lets each store look its own way without splitting the core logic into separate code versions.
04
In Lithuania, one buyer pays by card, another by bank transfer. Stripe and MakeCommerce are joined into a single flow, and every store has its own payout account, so money goes straight to the seller.
05
Speed has to hold beyond launch day. Server-side rendering combined with automatic Lighthouse checks before every change stops speed and SEO scores from quietly degrading.
06
If one store's emails land in spam, that shouldn't affect the others. Every store has its own sending configuration, so reputation is separated store by store.
07
With several buyers checking out at once, the same item must never sell twice. Stock changes go through database-level locks, so counts stay accurate even under heavy traffic.
08
Cross-border trade requires VAT-payer checks and data-protection compliance. Company VAT numbers are verified through VIES, and consent and data handling are set up to GDPR.
09
A broad system with several front ends and hundreds of data models easily becomes hard to maintain. A monorepo with shared libraries and type-checking from the interface down to the database makes it possible to change the system safely.
10
An AI agent makes more mistakes when handed dozens or hundreds of separate tools. The whole admin API is condensed into eleven topics — catalog, orders, analytics and so on — each holding many actions inside it. That lets the agent find its way faster and pick the right action more precisely.
11
Store search has to find a product even when it's typed without Lithuanian letters or with a typo. Search relies on PostgreSQL's full-text search tools: "dešra" is found when typed as "desra," and minor typos are smoothed over with similarity scoring.
12
Sellers point to external links — product photos on other sites, for example. Every such link is checked in advance so it can't be used to reach internal, non-public systems.
Advantages
Instead of several SaaS subscriptions that don't talk to each other, the platform, payments, tracking, email and analytics run as one whole.
Server-side tracking runs from day one, with no manual pixel installation per channel.
A new store is a configuration on a working core, not a new project built from zero.
Server-side rendering, structured data and automatic speed checks deliver good scores without extra work.
Every store sees only its own data — isolation holds at the database level.
Cards and bank-transfer links in a single flow, with direct payouts to every store.
New stores and capabilities are added to the same core, rather than built separately.
Content generation, natural-language administration and external AI-agent access all run on the same API, not a bolted-on add-on.
The platform runs on its own infrastructure, with no dependence on another platform's rules and percentages.
Specific solution recipes — the isolation mechanism, the deduplication logic, the queue structure — aren't shown publicly. Vantemo is an in-house, not-yet-public product; what's described here is its capabilities and architectural principles, not their implementation.