An AI-powered ecommerce platform for store owners who want a fully custom store without hiring a developer or understanding anything technical. The AI handles the storefront. The backend runs itself. The owner just runs their business.
Four distinct pieces that work together.
A fully managed REST API that handles everything a store needs on the data side. Merchants never interact with it directly — it runs in the background powering whatever frontend they've connected to it.
Every store gets its own API key. All data lives in a Postgres database — the merchant's data, not mixed into a shared blob. If they ever leave, they take a full database dump with them.
A web app the merchant uses to manage their store day-to-day. No code, no terminal — just a UI. Built in React, runs on its own port.
The admin dashboard is separate from the storefront. Merchants use it to run the business. The storefront is what customers see. The AI does not touch the admin dashboard — it works on the storefront only.
Merchants have two options:
Either way, once it's connected, the storefront talks to the CartD backend using the store's API key. Products, cart, checkout, orders — all live. The merchant deploys it to their own domain (Vercel, Netlify, their VPS — anywhere).
Two separate AI tools — one for wiring up the backend, one for editing the look and feel. Explained in detail below.
A store owner on Shopify who wants to change their storefront beyond what the theme settings allow has two options: hire a Shopify developer (expensive, ongoing dependency) or settle for what the theme gives them. Shopify Magic generates product descriptions — it doesn't change how the store looks or works.
On CartD, the owner clicks whatever they want to change and describes it in plain English. The AI makes the change. No developer, no ticket, no waiting. The store looks exactly how they want it to look — not how the theme allows it to look.
Shopify's model is to charge separately for almost every capability beyond the basics. Subscription products need a $99–500/mo app. Custom checkout flows require Shopify Plus at $2,300/mo. Extra staff accounts, advanced reporting, calculated shipping rates — all locked to higher plans. The app store is full of $15–50/mo plugins for things that should be standard features.
On CartD, the backend is a single API with no feature tiers. Subscriptions, custom checkout flows, custom product types — the backend is flexible enough to support them, and the AI handles the storefront side. The owner describes what they want; it gets built.
A merchant's entire business lives inside Shopify's platform. If Shopify changes pricing, removes a feature, or decides to compete in a category the merchant is in, the merchant has limited recourse. Migrating means losing metafields, custom data, order history — the CSV exports are lossy and the re-import process on any other platform is manual and painful.
On CartD, the merchant's data is in a standard Postgres database. Their storefront is their own code on their own domain. They can take it anywhere. CartD is infrastructure they use — not a platform they're locked into.
WooCommerce merchants chose it to avoid Shopify's costs, but ended up with a different problem: WordPress + plugin updates + security patches + hosting management. Every new feature is another plugin to vet, update, and hope doesn't conflict with the others. The store is cheap to run but expensive to maintain.
CartD is fully managed. The owner never touches the server, never updates a plugin, never deals with a conflict. They manage their store — products, orders, customers — and the AI handles anything they want to change about the storefront.
The problem it solves: A merchant imports their own React/Vue/Next.js template. That template has hardcoded product arrays, a fake cart, and no real checkout. It needs to be wired up to the CartD backend. Without this AI tool, that's a developer job.
The CartD REST API has a full OpenAPI specification — a machine-readable document that describes every endpoint, every parameter, and every response shape. We also write plain English docs (already live in Docusaurus). For the AI, we use the OpenAPI spec: it tells the model exactly what endpoints exist, what they accept, and what they return. No ambiguity.
They upload a zip of their project or connect a Git repo. CartD scans the code and identifies the data-fetching patterns — hardcoded arrays, mock fetch calls, placeholder objects.
The model receives the frontend files and the CartD API spec. It identifies what needs wiring — the products list, the cart add/remove, the checkout submit — and rewrites those specific parts to call the real CartD endpoints with the store's API key. It doesn't rewrite the whole project; it makes surgical replacements in the relevant files.
The wired-up frontend is shown as a diff. Merchant can review, accept, or adjust. Once happy, they deploy it to their domain. Done.
Why this is achievable: The AI is grounded in a fixed, known document (our API spec). It's a code generation task with a defined input and expected output — not open-ended reasoning. The 80% case (standard React with useEffect and fetch) is reliable with models like Claude or GPT-4o. Complex edge cases (unusual state management, non-standard patterns) may need manual review, but the bulk of common templates will wire up cleanly.
The problem it solves: Merchant wants to change how their storefront looks — different layout, different colours, add a section, rearrange cards. On Shopify they'd need a developer or be limited to theme settings. Here they just click and describe.
A lightweight proxy sits in front of the dev server and injects a small script into the page. This enables the editor overlay without modifying any source files.
Clicking a banner, a product card, or a nav item highlights it and opens a text box. The system identifies which source file and which line that element maps to.
The instruction and the relevant file are sent to the AI. The model returns only the changed portion as a diff (search/replace). The system validates the output — checks it parses correctly, doesn't break imports — and writes it to disk. If the first attempt fails validation, it retries with the error as feedback.
The dev server picks up the file change and the page updates. No build step, no deploy — the merchant sees it immediately.
Works today for straightforward edits. Complex React components with state, API hooks, and conditional rendering are less reliable with a single model. The architecture below addresses this — and is backed by how Cursor itself approaches the problem.
The single biggest lesson from Cursor, Lovable, and production AI coding tools: one model doing everything is not the answer. Cursor built their own proprietary model (Composer 2) specifically because general models fail on complex codebases — it was trained with codebase-wide semantic search built in and a separate execution layer. Research confirms the pattern: large model plans, small model executes — smaller model accuracy jumps significantly when guided by a planner vs. working alone.
Every merchant edit goes through two steps instead of one.
Claude reads all the storefront files and builds a persistent blueprint: what each component does, what state it holds, what sections are in it, what it depends on. Stored as JSON per merchant. Never repeated unless the file structure changes.
Merchant clicks a section and types their instruction. Claude receives: the instruction + the blueprint entry for that component (not the whole file). It outputs a precise technical spec — exactly what to find in the code, exactly what to replace it with, what to leave untouched. No code generation at this step.
Haiku receives the full file + Claude's precise spec. Its job is not to reason about React or understand the component — Claude already did that. It just implements the spec and returns a search/replace diff. Because it's executing instructions rather than reasoning from scratch, Haiku's tendency to hallucinate on complex components is largely bypassed.
Output is parsed by Babel. If it fails, retry with error feedback. Only write to disk if the result is valid. Storefront hot-reloads. Change is live.
| Action | Model | Tokens | Cost |
|---|---|---|---|
| Codebase scan on import | Claude Sonnet | ~15K in, ~3K out | ~$0.06 once |
| Planning step per edit | Claude Haiku | ~500 in, ~100 out | ~$0.002 |
| Execution step per edit | Claude Haiku | ~2000 in, ~300 out | ~$0.001 |
| Total per edit | ~$0.003 |
100 merchants × 50 edits/month = 5,000 edits. Total AI cost: ~$15/month. At 1,000 merchants × 50 edits: ~$150/month. No GPU, no server — just API calls.
Tested. llama-3.3-70b on Groq works for simple text and image swaps. On complex React components with state and API hooks, it produces broken output and needs multiple retries — sometimes still fails. Benchmarks confirm this: Haiku 4.5 scores 88.1% on HumanEval vs. open models in the 60–70% range. The gap is real and visible to users.
Free tiers also have rate limits designed for individual developers, not a product serving multiple merchants simultaneously. Groq's free tier is 12K tokens/minute — three merchants editing at the same time exhausts it instantly.
The plan-then-execute approach with Claude Haiku costs $0.003/edit. That is not a cost problem. It's not worth compromising quality to save it.
Done
Needed before launch
No GPU required. Infrastructure is: Fastify API server + Postgres database + Cloudflare R2 for images. The AI inference happens at the provider (Groq/Anthropic/OpenAI) — we just pay per call, no servers for that.
| Scale | API server | Database (Neon) | Storage (R2) | Our cost / mo |
|---|---|---|---|---|
| Under 50 stores | Free tier | Free tier | Free tier | ~$0 |
| 50–200 stores | ~$10 | ~$19 | ~$2 | ~$30 |
| 200–1,000 stores | ~$40 | ~$50 | ~$10 | ~$100 |
| 1,000+ stores | ~$150 | ~$100 | ~$30 | ~$280 |