Most website projects have a moment where one small request quietly turns into a project of its own. Mine arrived as a single sentence from a client: "Can customers add a few products to a basket and pay for them?"

The site was already well underway in Framer. The design system was in place, the CMS was populated, and the marketing experience felt sharp. Then ecommerce entered the conversation, and Framer ecommerce turned out to be the one thing the platform can't handle on its own.

Moving the whole project onto another platform to sell a short list of products felt disproportionate. So did adding a monthly ecommerce subscription to a site that mostly needed to look good and load fast. So I went looking for a third option, and ended up building the missing transactional layer myself, on free tiers, with AI as a development partner.

The running cost of everything I added is close to zero until a customer buys something. This is how it worked: the plugins I tried first, the architecture I landed on, and what it costs to run. It also covers what broke along the way, and when I'd tell you to buy a proper ecommerce platform instead.

‍

Framer ecommerce stops where the marketing site ends

‍

Framer has no native cart, checkout or order engine. It gives you a fast static site, a CMS, and more visual control than almost any other no-code builder. Anything involving money means connecting something external, either to Stripe directly or through a Stripe-powered plugin.

For this project, the client was a design-led business selling a small range of physical products. The marketing site needed to do exactly what Framer is good at: editorial layouts, strong imagery, quick pages. Customers would browse collections, then order.

Each collection page needed one button. Simple enough, until I mapped the real customer journey. That button had to support:

• adding more than one product
• adding multiple quantities
• removing products
• changing quantities inside the basket
• keeping the basket intact while browsing other pages
• showing product imagery in the cart
• calculating an accurate subtotal
• taking payment securely
• collecting a delivery address and contact details
• returning customers to a success or cancellation page
• sending an order confirmation
• notifying the business that an order had come in

That's not a button. That's a Framer shopping cart, a checkout, and an order system wearing a button's clothing.

‍

Why I didn't just add an ecommerce plugin

‍

The obvious first move was a third-party plugin, and I tried several. There are good ways to add ecommerce to Framer, and for most projects a plugin is the right answer. It wasn't the right answer for this one.

Compromises stacked up quickly. Some approaches introduced styling restrictions I'd have to design around. Some added another monthly subscription to a project whose entire budget argument was that it shouldn't need one. Some didn't sit cleanly alongside the CMS structure I'd already built. Others solved checkout neatly but left the basket experience feeling bolted on.

One pattern held across all of them. I was reshaping the website to suit the ecommerce tool, rather than adding ecommerce to the website I'd designed. For a business selling a handful of products, that felt like the wrong way round.

There was a second problem too. I'm a designer, not an ecommerce engineer. A custom React cart, a serverless payment endpoint, webhook verification and a transactional email system were not where I expected this project to go. Custom development sat firmly in the "probably not" column.

‍

The smallest ecommerce stack that would actually work

‍

‍

The unlock was changing the question. Instead of asking which ecommerce platform to add, I asked a smaller question. What is the minimum transactional layer this site needs, and how much of it can run on free tiers?

I already had the website, the CMS, the product content, the imagery and the design system. What was missing was much narrower than "ecommerce". Here's what I ended up with, what each part is responsible for, and what it costs:

• Framer: marketing site, CMS, product pages and UI. Already paid for as part of the website.
• React and TypeScript code components: the custom add to cart button and cart drawer. Free, and written once.
• Browser localStorage: a basket that survives page changes and refreshes. Free, and built into every browser.
• Custom browser events: communication between product buttons and the global cart, with no larger application framework needed. Free.
• Stripe Checkout: card payments, plus email, phone and shipping address collection. No monthly fee, charged per transaction.
• Cloudflare Workers: server-side checkout session creation and webhook processing. The free plan covers 100,000 requests a day.
• Cloudflare KV: a persistent record that stops the same order being processed twice. The free tier covers 100,000 reads and 1,000 writes a day.
• Resend: branded transactional emails to both the customer and the business owner. The free tier covers 3,000 emails a month, capped at 100 a day.

No Shopify store. No second ecommerce CMS. No traditional backend server. No new monthly subscription of any kind.

It's worth being clear about what kind of build this is. It isn't no-code, because there's real TypeScript involved. It also isn't a full application. The custom code amounts to one button component, one cart component and one Worker, sitting on top of a site that a designer still edits visually. Low-code is the accurate description.

AI didn't remove any of that complexity. It made the complexity accessible to someone who wouldn't otherwise have attempted the build.

‍

Building the cart was mostly a design problem

Products come from the CMS, state lives in the browser

Each product sits in the Framer CMS and passes the custom button everything it needs: product ID, name, price, Stripe Price ID, image and availability. Clicking the button writes that item to a basket held in localStorage, which gives you persistence between pages and refreshes without a database or a session service.

Then I placed the cart in the global navigation so the basket follows the customer around the site, and immediately broke it. The drawer inherited layout constraints from the navigation component, opened offset from the viewport, and clipped its own contents.

The fix was a React Portal. Rather than rendering inside the navigation, the drawer mounts directly to document.body and sits above the entire site as a proper full-height panel. Small change, large difference.

Four button states, one fixed size

The add to cart button ended up with four states: default, hover, added, and unavailable. Each one is styled through Framer controls, so a designer can keep adjusting typography, colour, borders and padding without opening TypeScript.

The button also had to hold exactly the same dimensions when its label changed from "Order" to "Added". Without that constraint, the whole component nudges the layout every time someone clicks it. It's a tiny detail, and it's the difference between an interface that feels intentional and one that feels improvised.

That became a working principle for the build: the code should add capability without taking control away from the designer.

A cart drawer is a modal, so I made it behave like one

Once the cart worked, I went back through it for accessibility, which is easy to skip on a component you've built yourself. According to the 2026 WebAIM Million report, 95.9% of the top one million home pages have detectable WCAG 2 failures, averaging 56.1 errors per page. That figure rose 10.1% on the previous year rather than falling.

So when the cart opens, keyboard focus moves into it and lands on the close button. Tab stays trapped inside. Shift and Tab works in reverse. Escape closes the drawer, and focus returns to the cart button that opened it. The page behind can't become part of the keyboard journey by accident.

Underneath that, quantity buttons carry descriptive labels, remove buttons identify the product they affect, cart changes are announced through an aria-live region, the checkout state uses aria-busy, and interactive targets were sized properly for touch.

None of it changed how the cart looks. It changed how many people can use it. And cart friction isn't a polish issue, it's a revenue one. Baymard Institute found that mandatory account creation drives 19% of checkout abandonments, with a long or complicated checkout responsible for another 18%.

‍

Taking payment is the easy half

‍

Payment ends the customer's journey and starts the business's. That second half is the part that's easy to underestimate.

I deliberately avoided building a payment form. Clicking checkout sends the basket to a Cloudflare Worker, which creates a Stripe Checkout Session using the Stripe Price IDs attached to each product. Stripe then collects the email, name, phone number, UK delivery address and card details on its own hosted page, then returns them to a success or cancelled page back in Framer.

Sensitive payment handling never touches the frontend, which keeps the compliance burden where it belongs.

After a successful payment, Stripe sends a checkout.session.completed webhook to the same Worker. The Worker verifies the Stripe signature before it does anything else, then pulls the authoritative order straight from Stripe: customer details, shipping address, line items, quantities, individual prices, total and product imagery.

That distinction matters more than it sounds. The order is rebuilt from Stripe's record, not from whatever happened to be sitting in the customer's browser.

The Worker then sends two emails through Resend. The business owner gets a new order notification with customer details, shipping information, products, quantities and totals. The customer gets a branded confirmation using the client's own logo, colours and typography, with replies routed to the business inbox.

Webhooks are designed to be retried, which means Stripe can send the same successful event more than once. Each checkout session gets a processing record in Cloudflare KV that tracks whether the owner notification went out, whether the customer confirmation went out, and whether the order finished processing. If the same event arrives again, the Worker sees it and stops. That's a lightweight audit trail, and it fits inside a free tier that allows 1,000 writes a day.

Getting this half right is worth the effort. Baymard estimates around $260bn in orders is recoverable across US and EU ecommerce through better checkout design, with an average conversion uplift of roughly 35% available from checkout improvements alone.

‍

What low-cost Framer ecommerce actually costs

‍

Close to nothing, until you sell something. That's the honest headline, and it's worth breaking down because "free" gets thrown around loosely.

The recurring bill for this system looks like this:

• Framer: whatever the site plan already costs. No increase for adding the cart.
• Cloudflare Workers and KV: nothing on the free plan. A store would need to pass 100,000 Worker requests or 1,000 KV writes a day before paying anything. The paid plan starts at a few dollars a month.
• Resend: nothing up to 3,000 emails a month. Each order sends two emails, so that's a lot of orders before the free tier runs out. The 100 a day cap is the one to watch during a launch or a sale.
• Stripe: no monthly fee at all. Stripe takes a percentage plus a small fixed amount per successful transaction, so the cost scales with revenue rather than arriving whether you sell anything or not.

Build cost is the real number, and it isn't zero. It's design and development time, plus the testing you'd want on anything handling money. What this architecture removes is the fixed monthly cost of an ecommerce platform, which keeps charging in the months when a small business sells very little.

‍

What this changes for design teams, and when to buy a platform instead

‍

There are developers who'd build this stack without breaking a sweat. That isn't the interesting part. The interesting part is that I'm a designer, not a developer, and the honest version of that story includes a lot of failure.

Imports broke. Buttons stopped responding. Images vanished. The cart got trapped inside its parent's layout. Test mode Stripe Price IDs got mixed with live mode products. Webhook secrets weren't available in the active Cloudflare deployment. Every one of those had to be diagnosed, understood, fixed and retested.

That experience is common rather than unusual, and it's a pattern I recognise from watching Untapped's clients too: founders bringing us something they have already built with AI. In Stack Overflow's 2025 Developer Survey of more than 49,000 developers, 84% now use or plan to use AI tools, up from 76% the year before. In the same survey, 45% said debugging AI-generated code is time-consuming, and trust in AI accuracy fell to 29%. Adoption is up, blind faith is not.

The useful thing AI did here wasn't writing code. It was keeping the project moving when it crossed the boundary between design and engineering. At every point where hiring a developer would normally have been the only route forward, I had something to iterate against instead.

The limits are worth stating plainly. I wouldn't use this architecture for a retailer with thousands of products, warehousing, stock control across channels, complex discounting or international fulfilment. At that point an established platform earns its subscription several times over, and you should buy one. Untapped's dev team does that too, and the trade-offs look completely different: building decimal-length fabric ordering on Shopify was a very different kind of problem. Custom ecommerce in Framer makes sense when the product range is small, the order volume is modest, and the alternative is rebuilding a site that already works.

‍

What I'd take into the next project

‍

Three things stuck with me. First, scope the transactional layer rather than the platform. I didn't need an ecommerce system, I needed a cart, a payment flow and an order process, and those aren't the same thing. Second, cart quality lives in the states and the accessibility work, not the visual design. Empty, added, hover, unavailable, loading, paid, cancelled and failed are all real screens.

Third, AI has moved what a designer can attempt, not what should ship without scrutiny. I reviewed, tested and deliberately broke every part of this build before it went near a real payment.

If your website has outgrown its no-code feature set, you may not need to rebuild it. We help businesses extend the platforms they already have with carefully designed functionality and integrations, usually for far less than a migration would cost. Tell us what your site needs to do next, or read more about what we build.

‍

Frequently asked questions

‍

Can Framer do ecommerce?

Not on its own. Framer handles the site, the CMS and the design, but it has no native cart, checkout or order engine. Selling means connecting Stripe directly, using a Stripe-powered plugin, or building a custom transactional layer like the one described here.

Does Framer have a built-in shopping cart?

No. A Framer shopping cart comes from a marketplace plugin or from custom React code components. If you build your own, localStorage handles basket persistence between pages, and a React Portal keeps the drawer from being clipped by whatever component you place it in.

How do you connect Stripe checkout to a Framer site?

The simplest route is a Stripe Payment Link, which works well for a single product but uses Stripe's branding and skips the cart entirely. For anything multi-product, you need a server-side step that creates a Stripe Checkout Session. I used a Cloudflare Worker, which also handles the webhook that fires after payment.

Do you need Shopify to sell on Framer?

No. Shopify is a strong option if you need inventory management, multiple sales channels and mature order tooling, and several plugins connect it to Framer as a headless backend. If you're selling a small number of products at modest volume, Stripe on its own is usually enough.

How much does it cost to add ecommerce to Framer this way?

Nothing extra per month at low volumes. Cloudflare Workers, KV and Resend all have free tiers that comfortably cover a small store, and Stripe charges per transaction rather than monthly. The cost that remains is the design and development time to build it, which is a one-off rather than a subscription.

When should you not build a custom cart in Framer?

When the operational side outweighs the design side. Large catalogues, stock control, complex shipping rules, subscriptions, discount engines and international tax all point to an established platform. Custom makes sense when the requirement is narrow, the design is the differentiator, and migrating the whole site would cost more than the feature is worth.