How to add a real backend to a Lovable store

Describing a storefront and watching Lovable build it is genuinely the fastest path to a good-looking shop that exists today. The frontend problem is solved.

The part that stops people is the second week. The store looks right, and then you need inventory that is correct when two people buy the last item at the same time, an order that still exists after you regenerate the page, and a checkout that moves real money. None of that belongs in generated frontend code, and no amount of re-prompting will make it belong there.

What has to live outside the generated code

A useful rule: anything that must still be true after you regenerate the page belongs in a backend.

That is a short list, and it is the same list for every store:

• Products, prices, variants. Hardcoded in the component, they are gone the moment you re-prompt that page.
• Stock. The only interesting case is concurrency — two shoppers, one item left. That is a database transaction, not a state variable.
• Cart. Carts in localStorage vanish when the customer opens your site on their phone instead.
• Payments. Card details must never reach your code. This is not a preference; it is what PCI scope means.
• Orders. The legal record of a sale. It cannot live in component state.

Everything else — layout, copy, animation, the entire look — is exactly what Lovable is good at, and should stay there.

The shape of the integration

Brainerce holds that list and exposes it over an API. Your Lovable app stays a frontend and calls it:

1. Create a store and add products in the Brainerce dashboard, or import an existing catalogue.
2. Get a sales-channel ID (it starts with vc_) from Store → Settings → Connections.
3. Point your AI assistant at the docs. This is the step people skip. Our integration guide at /docs/integration/core is written to be read by an assistant, not just a human — paste the URL into Lovable and ask it to build the storefront against that API. It covers products, cart, checkout, payment and orders end to end.
4. Deploy. Your frontend deploys wherever it already deploys; the data does not move.

The catalogue is fetched, not hardcoded. Adding a product later is a dashboard action, not a re-prompt.

Why not just use Shopify headless

You can, and for some stores you should. The trade is fees and control.

A headless Shopify setup means Shopify's per-transaction cut and Shopify's checkout. Brainerce takes 0% on transactions and you connect your own gateway — Stripe, PayPal, or Israeli processors like Cardcom, Grow, Max and Takbull. The money goes from your customer to your processor; we are not in the path, which is precisely why we can charge nothing per sale.

The honest counterpoint: Shopify's ecosystem is enormous and ours is not. If you need a specific app that only exists on Shopify, that matters more than the fee.

Things that will bite you

Collected from watching real integrations go wrong:

• Prices from the client. Never send a price from the frontend to be charged. The server prices the cart. If an API lets you pass an amount to charge, treat that as a red flag in any commerce API, not just ours.
• Regenerating the checkout page. Once checkout works, isolate it. Re-prompting a page that handles payment is how working flows quietly break.
• Testing with one browser tab. Concurrency bugs only show up with two. Add the last item to a cart in two windows and confirm exactly one sale goes through.
• Skipping the docs. Assistants hallucinate plausible-looking API calls when they are guessing. Given the real integration guide they do not have to guess.

Start

Create a free store — no card required — add a product, and hand the integration guide to Lovable. The frontend you have already built does not change.

The same approach works with Cursor, Claude Code, Bolt and v0: the docs are the interface, and the assistant is the one reading them.