Back to blog
Industry

Custom Ecommerce Development Is Mostly a Mistake — and the Part That Isn't Is Never the Storefront

Custom ecommerce development is wasted on the storefront. It earns its keep in the integration layer and the parts that genuinely differentiate you.

Dennis Vorobyov
Dennis Vorobyov
Founder & CEO
August 6, 2026 · 7 min read

Shopify moved roughly $292 billion in gross merchandise volume in 2024, across something close to three million merchants in more than 175 countries. That is the context for a conversation that happens in every growing brand around the eight-figure revenue mark: someone, usually a consultant or an agency with a deck, leans across the table and says you've outgrown the platform, you need to go custom, you need to own your stack. The number above is the reason that pitch is almost always wrong — and the reason that, when it's right, it's right about something other than what's in the deck.

The pitch, and the two lies inside it

There are two consensus positions on custom ecommerce development and both are sales positions. The first: custom means control, ownership, freedom from the platform tax, a system built exactly to your business. The second, increasingly fashionable: never build, platforms have solved commerce, anyone writing a custom checkout in 2026 is setting fire to money. The first is sold by people who bill for the build. The second is sold by people who bill for the subscription. Neither is describing your business; they're describing their revenue model.

The truth sits at an angle to both. The question is not custom versus platform. The question is which part of your commerce is genuinely yours and which part is a commodity you've convinced yourself is special. Almost everyone gets that line in the wrong place — and they put it around the storefront, which is exactly where it doesn't belong.

The cart is not your problem

The storefront — the product page, the cart, the checkout, the search box — is the most thoroughly solved problem in software outside of the login form. A platform processing hundreds of billions of dollars a year has run more checkout-conversion experiments before lunch than your custom build will run in its lifetime. It has handled fraud, address validation, tax in jurisdictions you've never heard of, payment routing, and the specific way a checkout has to behave on a four-year-old Android phone on a train. This is not a knock on your engineers. It's arithmetic. You will not out-engineer a checkout flow that has been tuned against billions of real transactions, and the months you spend trying are months stolen from the work that would actually move your business.

So when someone proposes a ground-up custom storefront because the off-the-shelf product page "doesn't quite match the brand," understand what's being proposed: rebuilding a solved system at full price to win a fight nobody but the design team will ever notice. A theme, a headless frontend, a few app integrations — that's a weekend of taste, not a custom platform. The expensive, defensible part of custom development is somewhere else entirely.

Where custom development actually earns its keep

Custom ecommerce development pays for itself in the connective tissue — the part no platform models because it's specific to how your business actually makes money. Two-sided marketplaces where money has to split between vendors. B2B pricing that depends on contract, volume, and customer tier. Inventory that lives in an ERP the platform has never met. Subscription logic that isn't a monthly charge but a usage-metered, prorated, mid-cycle-upgradable mess. Operational workflows — fulfilment, returns, reconciliation — that are your actual moat and that a generic admin panel turns into a daily clerical tax. This is where "the platform can't do it" is a real sentence and not a flattering one.

We saw the clean version of this with Nautical Commerce: a marketplace-as-a-service build we picked up on a roughly one-year-old codebase and delivered against a 90-day go-live. The platform we built has since handled 200,000-plus monthly transactions. The custom work that mattered there was never the storefront — it was the multi-vendor payment splitting on Stripe Connect, the onboarding, the marketplace mechanics that no off-the-shelf cart expresses. That's the tell. The justified custom budget went to the part of the system that was genuinely non-standard, and a marketplace build like that lands in the $80,000–$200,000 range depending mostly on how many external integrations and how much payment-flow complexity it carries — not on how pretty the listing page is.

"You'll own it" is the most expensive sentence in the pitch

The ownership argument is the one that survives the longest because it sounds like adulthood. Own your stack. Stop renting. The problem is that owning a custom ecommerce platform doesn't mean owning an asset — it means owning a liability that needs feeding forever. A platform is a system somebody else patches, scales, and stays awake for on Black Friday. A custom build is a system you patch, you scale, and you stay awake for. The day you ship is the day the maintenance bill starts, and it never stops.

That bill is survivable only if the team that built it is still there when something breaks at 2 a.m. in the fourth year, which is precisely where most custom ecommerce goes to die: the agency that wrote it has rotated three teams through your codebase, and nobody left can explain why the tax module does what it does. This is the unglamorous reason the build-versus-buy math so often goes wrong — it's calculated on the cost of building and never on the cost of carrying. We keep engineer turnover under 5% a year against an industry norm north of 20%, and every line goes through review by a second senior engineer before it merges, for exactly one reason: a custom platform is only an asset for as long as someone understands it. The moment that knowledge walks, you don't own a platform, you own a haunted house.

The replatforming graveyard

The most expensive way to discover all of this is the full replatform: the eighteen-month, all-at-once rewrite that aims to rebuild everything custom and reproduce the entire feature set of the platform you're leaving, plus the wishlist, plus the things the platform did that nobody documented. These projects don't fail because the engineers are bad. They fail because the scope is a hallucination — a fantasy of a finished state that the business outgrows before it ships. We've made a discipline out of the opposite move. On a stalled build called Meal4U we spent a week deconstructing scope and re-estimated it something like ten times, cutting 30 to 50 percent each pass until we found the smallest thing that could actually ship. That instinct — find the irreducible core, build that, refuse the rest — is the one that should govern any custom ecommerce decision, and it's the one the eighteen-month rewrite explicitly rejects.

Headless is the seductive middle — and often the worst of both

Composable, headless, best-of-breed: the modern compromise sells itself as the grown-up answer — keep the commerce engine, build the experience custom, snap in a search vendor, a CMS, a CDP. Sometimes that's exactly right. Often it's the worst of both worlds: you've taken on the maintenance burden of custom development and the licensing stack of four platforms, and the actual product you now ship is the glue between them. The integration layer is the system. Going headless doesn't remove the question of what to build custom — it sharpens it, because now every seam is yours to own. If you can't name the specific commercial reason the frontend has to be custom, headless is just a more expensive way to rebuild the cart you weren't supposed to be rebuilding.

This argument starts from first principles in what an MVP in software actually means. For how we actually run early-stage builds, see our ecommerce development work.

The only question worth asking

So here is the position, without the hedge: don't ask whether to go custom. Assume the answer is mostly no. Then go find the ten percent of your commerce that is genuinely non-standard — the marketplace split, the contract pricing, the ERP integration, the operational workflow that is actually how you win — and build that part custom, well, with a team that will still be there to maintain it. Rent everything else, including the storefront you were so sure was special. The brands that get this right don't have a custom ecommerce platform. They have a commodity platform doing the commodity work and a sharp, small, custom system doing the one thing nobody else can do for them. The brands that get it wrong spent two years and a marketing budget rebuilding a checkout that already worked. Custom ecommerce development is a scalpel. Most people are buying it as a flag to plant, and that's why most of the money spent on it is wasted.

Related posts

Need engineers who think this way?

Senior developers on retainer. Same team, month 1 and month 36+.

Talk to us