Own the Front Door: Taking Back a Platform You Can't Configure

Most businesses run on someone else's engine now. A commerce platform, a fulfillment system, a white-label portal. It does the heavy lifting and it does it well. The trade you make for that is control: you get the settings the vendor decided to expose, and not one more.

On a recent project we ran straight into that wall, and the way out turned out to be more interesting than the problem. We didn't replace the platform. We didn't hack it. We put a layer in front of it and took the customer experience back.

The wall

The business was built on a platform that handled everything behind the scenes, and the back end was the right call. The front end was the problem. Things showed up on screen that the business didn't want customers to see. Buttons sent people where the platform wanted them to go, not where the business wanted them to go. And there was no way to change any of it. No access to the HTML. No control over where the links pointed. No setting anywhere for the behavior that mattered.

Then there was checkout. The business didn't run on one platform; different parts of what it sold came from different back ends, and each back end had its own cart and its own checkout. To a customer it looked exactly like what it was: several systems stitched together. That's not cosmetic. Checkout is where trust holds or breaks.

The usual options are to live with it, wait for the vendor to ship a feature, or start over somewhere else. None of those were good.

Own the road in front of the engine

So we put a Cloudflare Worker in front of everything.

Customers no longer talk to the platforms directly. The business's domain points at the Worker, and every request passes through it first. The Worker fetches the page from the platform, changes it on the way through, and hands the result to the browser. The platform still does all the real work. It just doesn't get the last word on what the customer sees anymore.

That one move gave us four things the platform didn't offer.

Suppress. Elements the business didn't want shown are removed before the page ever reaches the browser. Because the change happens at the edge and not in the browser, nothing flashes on screen and then disappears. It simply isn't there.

Redirect. Some things we left exactly as they were and changed only what happens when someone clicks them. The button looks the same. It just goes where the business wants it to go.

Intercept. Every click and request crosses our layer before it reaches the platform, so we decide what gets passed through, what we handle ourselves, and what gets sent somewhere else entirely.

Consolidate. This is the big one. We pulled the cart and checkout out of the platforms and brought them up into the layer we own. Now there is one cart and one checkout, in one consistent experience, no matter which back end fulfills the order. Behind the scenes, each order goes to whichever platform makes it. The customer never sees the seams.

Owning checkout changes what you can sell

Once the cart belonged to the business instead of the vendor, it stopped being limited to what one vendor's checkout supports. Options, configuration and items the customer simply could not add before can now be offered, because the cart is no longer the platform's. That's the part I didn't fully appreciate going in: taking checkout back isn't only about looking unified. It changes what the business is able to offer at all.

What it costs you

None of this is free, and I'd be doing you a disservice if I made it sound that way.

Owning checkout means owning everything checkout carries: payments, order records, customer accounts and order status are yours now, not the vendor's. Use a reputable payment provider and plan that part with more care than anything else in the build.

Every handoff has to be mapped. Each back end needs to receive orders in the shape it expects, and you need to know exactly what happens when one of those handoffs fails.

The page rewriting depends on markup you don't control. When the vendor ships an update, your rules can quietly stop matching. Watch for it, and build the layer to fail open: if a rewrite breaks, serve the original page. A plain page beats a broken one.

And read your vendor terms before you start. Fronting a platform this way is a legitimate pattern, but make sure your agreements allow it.

The lesson isn't about Cloudflare

It's about where control actually lives. If you can't change the engine, you can still own the road in front of it. And if you run on more than one engine, owning that road is how several systems become one business in the customer's eyes.

Before you rip out a platform because it won't bend, ask whether you need a new engine, or just a layer in front of the one you already have.