How CartSome
is wired.
CartSome is a whole shop — storefront, checkout, delivery and admin — that you run from the AI client you already use. Built by people who build banks, and fast because we measure it. Underneath: a cell that serves the shops, a control plane that runs the platform, a hard line between them, a schema per shop and cells that hold a few hundred shops each. Here's how it fits together, what the AI may touch, and how a shop moves in. No buzzwords were harmed.
- Built by people who build banks
- Shops and platform on separate cores
- A schema and two logins per shop
- Cells of about 300 shops
- 314 store actions over MCP, with undo
Built by people
who build banks.
Speed is our DNA. So is not losing your money. CartSome is built by people who build banks, and it shows in the unglamorous places: one writer for money and stock, a trail for every act, a preview before every big write, and a number behind every claim.
- Correct first, then fastMoney and stock have one writer, shop-core. Payments are verified on the server, never trusted from the browser, and the browser does its sums in whole cents.
- Everything leaves a trailEvery grant or removal of access is recorded in the same transaction as the act, and every operator act on the platform's trail.
- Boring on purposePostgreSQL, Java, raw SQL and Terraform: tools that will still be here in ten years, with no clever layer to debug at 3 a.m.
- Measured, not guessedEvery change to how the storefront reads is benchmarked against a 500,000-product catalogue before it ships. A hunch is where a benchmark starts, never where it ends.
Fast, and held there by gates
the budget for an uncached listing page at p95, on a 500,000-product catalogue. A filter, a scroll or a search gets 150.
layout shift on autotools.ee's home and product pages, with under 30 ms of blocking time. Measured 29 October 2026.
heavier than main is enough for a page to fail the speed gate.
- Rendered on the server, cached at the edgePages arrive as HTML in the shopper's language, and shop-core keeps listings and product pages warm in Valkey.
- A byte budget in CIThe storefront's entry, shell and every route chunk are held to a budget on every change, and the budget only moves down. Each language ships in its own chunk, so a shopper downloads one.
- A speed gate before releaseIt builds main and the change side by side and fails a page that gets heavier, or slower in Lighthouse on load, layout shift or blocking time.
- A worst-case gateEvery theme option at its heaviest, every section type at once, and the shop still may not get slow. Themes are CSS variables, so a theme ships no JavaScript at all.
- Light picturesEvery product image is resized into AVIF variants, and static files go out precompressed with brotli.
Two halves.
A hard line.
Most platforms grow a service per feature. We split in exactly one place: the shops on one side, the platform on the other. Each half has its own app, its own core, its own database login and its own half of the key. And the old rule holds on both sides: only a core writes.
- shop-core — the cell, in Java 25 and Spring BootThe only writer of the shops' data in PostgreSQL, Valkey and S3. Every admin change, import, payment and shop job goes through it. It sits off the public internet, verifies every payment webhook and signature itself, and opens the shops' sealed secrets.
- platform-core — the control planeThe same code base, built as a second application with its own image: the console's backend, billing, organisations and onboarding, the platform's own mail and the control plane's jobs. Its database login reaches no shop's schema, and it runs no migrations.
- The Cell API between themThe two cores talk over two internal doors, one per direction, each with a secret of its own. Each door keeps only a SHA-256 of the secret it accepts, so neither core holds anything that opens its own door. No shopper's request waits on the control plane.
- shop web — TanStack Start, React, server-renderedRenders every storefront in the shopper's language, the shop admin, the admin MCP and the Trade API's door. It reads Valkey, and PostgreSQL on the shop's own read login, and writes nothing but sign-in sessions; every other write goes to shop-core.
- The console — an app of its ownA separate app and image for admin.cartsome.com, the operator MCP, cartsome.com's forms and Stripe's webhook. It has no database driver, holds no shop's secrets and talks to platform-core alone.
- The edge — CloudFront and WAFPages are cached at the edge and images come straight from S3. The load balancer behind it answers CloudFront alone, sends each address to the app that serves it, and a flood aimed at one shop is stopped at the edge, per shop address.
- Aurora PostgreSQL 18, raw SQLNo ORM, anywhere. Full-text search runs in PostgreSQL too, in the shopper's language and forgiving of typos. No separate search cluster to babysit.
- Valkey and S3Valkey holds the pages shop-core warms ahead of shoppers. S3 holds product images (AVIF variants), theme fonts, a product feed per language and the export of a shop that leaves.
- Containers on ARMThe four services run on ECS Fargate, on Graviton, each from its own image, and the picture workers run on Lambda, on ARM as well. Terraform describes all of it, and nothing is clicked together in a console.
Pictures, on a queue
A shop moving in brings thousands of pictures, and a new shop shouldn't slow anyone's checkout while they're drawn. So shop-core doesn't draw them.
- The core only enqueuesShop-core puts each picture task on SQS and records the answers as they come back, in batches, one transaction per shop. The workers hold no database login at all.
- A fair queue per shopEach shop is its own group on SQS fair queues, with an interactive lane for a picture an admin uploads and a bulk lane for imports, and a cap per shop in each. One shop's big import never stands in front of another shop's one photo.
- Same encoder, more handsLambda workers run the same libvips encode the core runs, so a picture looks the same whoever drew it. Downloads are paced per source host, so a supplier's server isn't flooded.
- Drawn once, used everywhereA picture is known by the hash of its bytes. When any shop in the cell has drawn the same source already, the workers reuse its files instead of encoding again.
- Built for the rushThe fleet scales out when many shops move in at once and costs nothing when idle, and the admin shows each run live: done, reused, failed, waiting and its place in the queue.
The whole thing,
on one page.
Who talks to what, from a shopper's phone down to the disks. Solid lines carry requests and writes; dashed ones only read.
The map, in words
- Who knocks. Shoppers (people and AI shopping agents), other businesses' systems on the Trade API, a shop owner's AI client, shop admins and CartSome's operators all come in through the edge.
- The edge. CloudFront caches pages, serves images straight from S3, holds the certificates for every *.cartsome.com address and each shop's own domain, and its WAF limits each shop address on its own.
- The load balancer answers CloudFront alone. It sends every shop's address to shop web, and admin.cartsome.com and cartsome.com's API to the console.
- Shop web renders the storefront, the admin and the admin MCP, a public MCP for shopping agents that each shop switches on itself, and the Trade API's door. It reads PostgreSQL and Valkey and hands every write to shop-core.
- The console serves admin.cartsome.com, the operator MCP, cartsome.com's forms and Stripe's webhook, and talks to platform-core alone.
- Shop-core is the cell: the only writer of the shops' data in PostgreSQL, Valkey and S3. It verifies webhooks, opens the shops' vault and puts picture work on the queues.
- Platform-core is the control plane: organisations, onboarding, billing, the platform's mail and its jobs, on a database login of its own. It reaches the cell only over the Cell API, with one secret each way.
- The picture workers take tasks from SQS fair queues, a group per shop, encode them on Lambda and write the files to S3.
- The data: Aurora PostgreSQL with the platform schema and a schema per shop, Valkey with each shop's warm pages, and S3 for images, fonts, feeds and exports.
- Cell 1 runs all of that in Stockholm today. Cell 2 is the same stack again, opened when it's needed, in whichever AWS region its shops need.
A request's life
The address picks the shop
The edge passes the shop's real address. Shop web maps it to one shop and binds that shop for the whole request.
Reads stay close
A warm page comes from Valkey; anything else is read on the shop's own read-only login.
Writes go to shop-core
Web forwards the write with the shop named. Shop-core checks the shared secret, then writes on the shop's own login.
Caches catch up
Shop-core clears that shop's affected pages from the cache, so the next shopper sees the new price.
Your shop.
Your schema.
Many shops, one database cluster, zero shared shop tables. Each shop gets a PostgreSQL schema of its own, and the database itself keeps the neighbours out.
- A schema and two loginsShop n lives in its own schema, built from one baseline. Shop web signs in with the shop's read login, shop-core with its write login, and neither reaches any other shop. Platform-core's login reaches no shop at all.
- No shop column to forgetTables keep their shape inside the schema: no shop id on every row, no filter a query could leave out. Foreign keys never leave the schema.
- Statements never name a schemaThe login a connection signs in as picks the shop, and a connection serves one shop for its whole life. A static check fails the build on a schema name in a query.
- Pools that open on demandEach shop gets small connection pools of its own, opened on its first request and closed once it goes quiet, so the database's connection budget limits how many shops are busy at once, not how many exist. Each shop has its own request budget too, and a shop past it is told to retry, alone.
- Caches and links know their shopEvery cache entry is keyed by shop. Sessions, order links, gift-card links and unsubscribe tokens are signed with the shop's own keys, so one shop's link is refused on another.
- A leak suite that tries the doorsIt seeds a row in every per-shop table for two shops and reads each as the other, on shop-core's connections and shop web's, then calls every core endpoint that takes an id. It runs on every change.
Cells, not
one big blob.
We scale by cells. A cell is a complete stack: its own Aurora cluster, its own shop-core and shop web, its shops' schemas, its own picture queues and workers. When one fills up, we open another. The control plane sits apart and speaks to a cell only through the Cell API. The platform grows; no single cell has to.
shops in a pooled cell. Measured, not guessed: a 1,000-shop test cell ran out of memory twice.
cell: cell 1, in AWS Stockholm. Autotools lives there, and so does every new shop, for now.
more cells, built from the same Terraform modules, opened as needed in whichever AWS region their shops need.
What "full" means
A cell takes no new shop once any of these reaches its cap. At 80 percent of any cap we plan the next cell; the console's Cell page shows the live fill and names the signal.
| Signal | Full when |
|---|---|
| Shops | about 300 in the cell |
| Database capacity | Aurora runs near its ceiling for minutes on end |
| Connections | the connection budget would pass what the cluster allows |
| Shop pools | shops are refused connections while the database has headroom |
| Cache memory | Valkey nears its memory ceiling |
| Migrations | a migration wave across the cell's schemas fails or stops |
- A big shop gets a cell of its ownA shop that outgrows a pooled cell gets a cell to itself. Autotools stays in cell 1.
- Portable by constructionEverything a shop owns is named by the shop: its schema with its own keys and sequences, its vault rows sealed under its organisation, its cache keys, its feed files. Nothing ties it to the cell it was born in.
- Honest bitMoving a shop between cells isn't a button yet. It arrives with the second cell, and nothing in the way is shared.
Locked by default.
Boring on purpose.
The interesting part of a shop should be the products. Here's the boring part, at the level we're happy to publish.
- Isolation in the databasePer-shop schemas and logins, enforced by PostgreSQL grants rather than by code remembering a filter. The control plane has a login of its own, and shop-core's login holds no right on the control plane's tables.
- A sealed vault per organisationPayment, carrier and mail keys sit in the vault, each sealed with AES-256-GCM under a fresh data key from a KMS key only the two cores can use, and bound to its organisation and name. A copied row opens nowhere. Secrets never live in code.
- Each core holds half the keyShop-core opens the shops' secrets and platform-core the platform's own, like its Stripe and accounting keys. The key's policy refuses either the other's half.
- Two doors, two secretsThe cores call each other with one secret per direction, and each door stores only the SHA-256 of the secret it accepts, so neither core holds what opens its own door.
- Passkeys for the people who run itOperators sign in with passkeys and confirm every platform change with a fresh one. Granting access is never a tool: no token, and no AI, can add an operator.
- AI writes you can see and take backBulk and outward-facing writes run as a preview first and apply on a confirmation that binds what you saw; if the shop changed in between, it's refused. Then every write answers with its undo.
- Tokens with the smallest key ringEach admin MCP token or connection carries scopes, and sees only the tools those scopes allow. Refunds, secrets and admins each need a scope of their own.
- Customers stay out of the chatA tool's answer travels to the AI provider, so answers leave out shoppers' names, emails, phones, addresses and tax ids. The few stated exceptions, like the words of an order comment, are named in the rules.
- A trail for every operator actEvery change an operator makes, and every read across shops, lands in the platform's audit trail.
314 actions.
Zero forms.
The admin MCP gives an AI client 314 store actions, and every one of them is in the web admin too. Connect Claude, ChatGPT, Cursor, Gemini or any other MCP client with a sign-in or a pasted token. The switch is off until an admin turns it on.
Catalogue and pricing.
Products, families, tags, menus, attributes, imports, price rules, sales, bundles and coupons. tag_products, manage_family, explain_price.
Orders and stock.
Find an order, move it along, comment, request labels; warehouses, stock counts, supplier orders and trade accounts. Refunds need their own scope.
Content and storefront.
Homepage layouts, pages, blog, FAQ, theme, announcements, search words and what search engines and AI assistants read.
Marketing and email.
Sign-up form, campaigns, welcome series, flows and message templates. A campaign is scheduled only after its preview.
Settings and setup.
Languages, markets, delivery, checkout, sign-in, apps and the before-you-open checklist. manage_languages, set_shop_open.
Image studio.
Draws pictures for products, categories, slides and email banners, with your own photos as references, and shows the client what it drew before it goes anywhere.
The safety model
Read
The client reads the shop as it is. Every write has a read that shows the ids it takes.
Preview
A bulk or outward-facing write first answers what it would change, a count and a sample, and changes nothing.
Confirm
You say yes. The apply checks the shop again and refuses a preview the shop has outgrown.
Undo
The answer carries its undo, spelled as the call that puts things back. The few that can't say why: a sent email, refunded money, a replaced key.
Scopes shape the surface
A token sees only the tools its scopes carry, so a narrow token is a small surface as well as a small power. Tags and menus are separate scopes, because a published menu changes what shoppers see at once. Drafting a post and publishing it are two. Nothing an AI can do confirms an accounting booking; a person does that in the admin.
Examples
“Show the new Bosch range in the shop.”
list_products set_shown_in_shop
Outcome: a preview of the hidden products by brand, then one call that shows the whole range, and the ids that hide it again.
“Move my old site's addresses so Google still finds every product.”
check_redirects import_redirects
Outcome: your old export checked row by row, chains folded into one hop, the unmatched listed for you, then a dry run before anything is saved.
“Draw a winter banner and get the campaign ready for Friday.”
generate_image draft_campaign schedule_campaign
Outcome: the banner shown in the chat, a drafted campaign, and a schedule only after you've seen its preview.
↑ Example requests · the tools named are real
Shop to shop.
No middleman.
Every shop can open a Trade API to its business customers: a neutral, versioned HTTP API their own systems call to read the catalogue at their prices and place orders. And any shop can buy from any other shop that speaks it, as one more supplier.
- A protocol, not a brandDiscovery at
/.well-known/trade-api, the API under/trade/v1, an OpenAPI 3.1 document, and no platform's name anywhere in it. A seller that speaks it is a seller, whatever runs it. - Keys the customer makesAn admin approves a business as a trade account, pins the price tier it buys at and allows the API. The customer mints and revokes their own keys on their account page; the shop keeps only a hash, and no admin ever sees a key.
- Their prices, real stockEvery product is priced exactly as the storefront prices it for that customer signed in, with the storefront's sellable stock beside it, capped.
- Orders that can't doubleEvery order carries an idempotency key: the same key and body return the first order, and a different body is refused. From then on it's an ordinary order of the shop, invoiced, packed and shipped the usual way.
- Buy from any shopA generic trade-supplier connector makes a seller one more supplier: its stock and prices are read on a schedule, orders go out under an idempotency key, and confirmations and deliveries are read back. It calls the seller's public address like any stranger, never a shortcut inside the cell.
- A short leashLimits per key on requests and orders, a cap on unpaid orders, and a key of one shop is a stranger on another. Every account, access and key act lands in the shop's audit trail, and the customer hears of every new key.
- Honest bitNo webhooks yet: a buyer polls for what changed. Orders are paid by prepayment invoice for now; paying on account comes later.
A shop in minutes.
Open when ready.
There's no installer and no server to pick. We add your organisation on the platform console, the shop builds itself, and you take it from there.
Organisation and shop
Your company, the shop's name and its main language. Your own domain can come now or later.
The shop builds itself
Its schema, logins, signing keys and feed path are made off the request, in the background. It starts closed to the public.
An address at once
yourshop.cartsome.com answers the moment the shop is active: one wildcard certificate, no DNS step.
The key and the first admin
A single-use onboarding key, handed over in person or by call, never by email. Your first admin opens /setup and makes a passkey.
Before you open
Payments through Montonio, delivery rates, languages, shop details, a product to buy. Each step is a page and an MCP tool.
Open, then your domain
Open when the checklist is done. Point your domain with one DNS record and we add it at the edge; once it answers, it becomes the main address.
Languages, on a switch. A new shop starts with its main language and Estonian. Turn on any of the 8 when its translations are ready, on Settings › Languages or with manage_languages. A product keeps the same address in every language.
Bring your shop.
Keep your Google.
Autotools moved from Shopify and runs 25,000+ products on CartSome today. The tools it took are the tools you get.
- Products, converted by AI and checked by a personYour AI client reads the import format, the shop's vocabulary and the supplier's data, and writes a file the shop's own validator passes. It stops and names every gap instead of inventing a category. A person reviews what matched and what's new, and only an import they name is applied, by confirming a preview they read.
- Hidden until you say showNew products arrive hidden. One previewed call shows a whole range of up to 5,000.
- Old addresses, redirectedHand over Shopify's redirect export or any two-column list. Each row is matched the way the storefront looks addresses up, chains are folded into one permanent redirect, and every target is checked against the shop's own pages.
- The Shopify cutover kitOur cutover tools snapshot the old site, build the old-to-new address map with a report of what's left, and then ask the new shop every row, requiring one 301 to a page that answers. Autotools carried 12,598 old addresses across this way.
- Newsletter consent, moved onceThe marketing list moves into the shop's consent ledger with each person's answer as given. It sends nothing in the move.
- What stays behindPast orders stay on the old platform. Keep its export for your books.
An example move
Kick-off
Access to the old shop, and an agreement on what comes over.
Bring-over
Catalogue, pictures and customers into a new shop at its cartsome.com address.
Your review
Old shop against new, page by page, and a test order. We fix what you find.
Switch
Redirects verified, then one DNS record. The old shop sells until that moment.
↑ An example · the size of your catalogue sets the pace
How a move worksEngineers ask.
We answer.
What's the stack, exactly?
Java 25 with Spring Boot for the two cores, TanStack Start with React 19 for shop web and the console, Aurora PostgreSQL 18, Valkey 9, S3 and CloudFront, with SQS and Lambda for the picture workers. The services run on ECS Fargate on ARM, all described in Terraform. Raw SQL everywhere: no ORM.
How fast is it, really?
Run Lighthouse on autotools.ee yourself. On 29 October 2026, on its phone profile, the home and product pages showed zero layout shift, under 30 ms of blocking time, and 100 for accessibility, best practices and SEO; cartsome.com scored 100 in all four categories. Behind that: a byte budget in CI, a speed gate and a worst-case gate before release, and listing pages budgeted at 250 ms at p95 on a 500,000-product catalogue.
Why split core in two?
So a shop's traffic and the platform's business never share a process or a database login, and neither side can open the other's secrets. Shop-core serves the shops and can't open the platform's secrets; platform-core runs the console and billing and can't read a shop. If the control plane is down, shops keep selling.
Is it multi-tenant, and how isolated is a shop?
Yes. Every shop has its own PostgreSQL schema and its own two logins, so isolation is the database's job, not a filter in code. Caches, sessions and signed links are bound to the shop, and a leak suite reads every per-shop table as another shop on every change.
What happens when a cell fills up?
It stops taking new shops, and the next cell opens. We plan it when any signal (shops, database capacity, connections, cache memory, migrations) reaches 80 percent of its cap, so a cell stops taking shops before it is full.
Where does my data live?
In Amazon Web Services' Stockholm region (eu-north-1) today. Your shop's rows sit in your shop's own schema, and its keys in your organisation's sealed vault.
Can I get my data out?
Yes. When a shop leaves, its whole schema is exported with pg_dump, and pg_restore reads that file into any PostgreSQL 18 database.
Can my business customers order from their own systems?
Yes, once you allow it. Approve them as a trade account and they make their own Trade API keys, read your catalogue at their prices and place orders, each under an idempotency key so a retry never orders twice.
Does customer data reach my AI provider?
Not by design. Tool answers leave out shoppers' names, emails, phones, addresses and tax ids, and tests fail if one slips in. The stated exceptions are an order's activity, the words of a comment and staff names on comments.
Can the AI refund an order or change a payment key?
Only with a token you minted with that exact scope. Refunds are a scope of their own; secrets and admins come only on a pasted token an admin minted on purpose, never through a one-click app connection.
Which AI clients work?
Any client that speaks MCP: Claude, ChatGPT, Cursor and Gemini among them. They connect with a sign-in or a pasted token, and see only the tools their scopes allow.
How does search work without a search cluster?
PostgreSQL full-text search in the shopper's language, with trigram matching for typos and part numbers. One less system to run, and it is benchmarked against a 500,000-product catalogue before changes ship.
Can I extend it?
Yes. Install a reviewed app from the marketplace or build your own with your AI client. Each runs in its own sandbox and installs switched off.
Let's make
commerce interesting.
Tell us about your shop. We'll move it for you and you talk to the engineers who build it.
Let's talk