Every few months a founder or a CTO asks whether they should just build it. The reasoning is usually sound on its face: we have engineers, we know our business better than any platform does, we would own everything, and we would not pay a subscription forever.<\/p>\n
I want to take that seriously rather than dismiss it, because there are cases where building is correct. But I also want to be direct about what you are actually signing up for, because the cost is consistently underestimated \u2014 and the part people underestimate most is not the build.<\/p>\n
Be clear about scope first, because the word covers three very different things.<\/p>\n
Fully custom<\/strong> means building the commerce platform itself: catalogue, cart, checkout, payments, order management, inventory, admin, the lot. You own every line and every obligation, including PCI compliance for card handling.<\/p>\n Headless with a commerce backend<\/strong> means building a custom storefront while a platform handles commerce and checkout underneath. Shopify’s Storefront API<\/a>, Hydrogen<\/a>, and headless builds<\/a> live here. You get front-end freedom without rebuilding the risky parts.<\/p>\n Custom on a platform<\/strong> means using Shopify normally but building whatever bespoke functionality you need through custom apps<\/a>, Functions, and integrations.<\/p>\n When people say “build our own,” they usually mean the first. Very often what they actually need is the second or third, and realising that saves an enormous amount of money.<\/p>\n The build is the part everyone budgets for. Here is what tends to get missed.<\/p>\n The checkout is not a feature; it is a discipline.<\/strong> You are handling card data, which puts you in PCI scope. You need fraud prevention, 3D Secure and strong customer authentication where required, wallet payments, saved cards, failed-payment handling, refunds, partial refunds, and chargebacks. Shopify’s checkout is among the most optimised on the internet because Shopify has spent a decade and enormous resources on it. Yours will not match it, and every conversion point you give up is revenue forever.<\/p>\n Security is permanent.<\/strong> Dependencies need patching, vulnerabilities need responding to, and a breach on a system you built is your liability in a way a platform breach is not. That is not a project; it is a standing obligation with no end date.<\/p>\n Compliance keeps moving.<\/strong> Tax rules change. Privacy law changes. Accessibility requirements tighten. Payment regulations shift. On a platform, most of that arrives as an update. On your own system, each one is a ticket.<\/p>\n The admin is a product too.<\/strong> Your operations team needs order management, inventory, refunds, fulfilment, reporting, staff permissions, bulk editing. Shopify’s admin represents years of refinement, and every hour your team loses to a worse one is a real cost you will not see on any invoice.<\/p>\n Integrations are yours to build and keep working.<\/strong> No app store. Every payment provider, shipping carrier, tax service, email platform, review tool, and analytics connection is bespoke work, and each one breaks when the other side changes.<\/p>\n Scale is your problem.<\/strong> Traffic spikes need provisioning and load testing. The day you get the most attention you will ever get is the worst day to discover you got it wrong.<\/p>\n And the team must persist.<\/strong> This is the one that kills custom builds. A platform someone built and left becomes a liability nobody wants to touch. You are committing to keeping commerce engineering capability for as long as the store exists, through hiring markets and budget cycles you cannot predict.<\/p>\n There are real cases, and they share a characteristic: the commerce model itself is the product, not a way to sell the product.<\/p>\n Your business model is not retail.<\/strong> Marketplaces with multi-vendor payouts, rental or resale platforms with complex inventory states, auction or bidding models, usage-based billing, or anything where the transaction logic is fundamentally different from “customer buys item.” Platforms assume retail; if you are not doing retail, the assumptions fight you.<\/p>\n Commerce is embedded in a larger product.<\/strong> If selling is one function inside a bigger application \u2014 a SaaS product with a marketplace, a service platform with transactions \u2014 building commerce into the application is often cleaner than bolting on a separate store.<\/p>\n You operate at a scale where platform fees exceed engineering costs.<\/strong> At large volume, revenue-linked platform fees can exceed what a capable in-house team costs. That crossover is higher than most people estimate and the calculation must include everything above, but it exists.<\/p>\n Regulatory or data-residency constraints rule out SaaS.<\/strong> Some sectors and jurisdictions require control that a hosted platform structurally cannot provide.<\/p>\n Commerce is your competitive advantage.<\/strong> Rare, but real. If how you sell is what differentiates you \u2014 not what you sell \u2014 owning that system may be strategic.<\/p>\n Notice what is not on this list: wanting more design control, disliking subscriptions, having engineers who would enjoy it, or needing a feature no app provides. Those are all solvable within a platform, usually for a fraction of the cost.<\/p>\n Here is the option that resolves this for the large majority of people asking.<\/p>\n Keep Shopify as the commerce engine \u2014 catalogue, cart, checkout, payments, orders, admin \u2014 and build custom exactly where you need it. A headless storefront in Hydrogen or Next.js if the front end is your differentiator. Custom apps for bespoke logic. Functions for pricing, shipping, and validation rules the standard tools cannot express. Custom integrations into your internal systems.<\/p>\n You get the custom experience and the bespoke logic, and Shopify keeps handling the checkout, PCI compliance<\/a>, scaling, security patching, and the admin your operations team lives in. The risky, expensive, permanently-obligating parts stay with the platform.<\/p>\n For nine out of ten brands who arrive at “should we build our own,” this is the answer they actually wanted. It is worth testing seriously before committing to the full build, because the cost difference is enormous and the capability difference is usually small.<\/p>\n A subscription brand with a unusual model \u2014 variable bundles, complex proration, customer-specific pricing that changed with tenure \u2014 came to us convinced they needed a custom platform. Their engineering lead had scoped it and the estimate was substantial but not absurd.<\/p>\n The scoping conversation went differently than they expected. We worked through their requirements one at a time and asked, for each, whether Shopify could express it. Variable bundles: yes, with a custom app. Proration: yes, through their subscription platform’s API with custom logic. Tenure-based pricing: yes, via Functions. Custom customer portal showing their unusual plan structure: yes, built against the APIs on their own domain.<\/p>\n What they would have rebuilt from scratch \u2014 checkout, payments, PCI scope, order management, inventory, the admin, fraud handling, tax \u2014 was all functionality they had no unusual requirements for at all. They were planning to spend most of their budget rebuilding commodity infrastructure in order to get four features.<\/p>\n They built the four features on Shopify instead, for a fraction of the estimate and in about a quarter of the time. Two years on they have no in-house commerce platform team, which is the cost they never priced in the original plan.<\/p>\n The general lesson: separate the requirements that are unusual from the ones that are just requirements. Almost always the unusual list is short, and almost always it can be built on top of a platform rather than instead of one.<\/p>\n Should you decide custom is right, a few things make the difference between a good decision and an expensive one.<\/p>\n Do not build the checkout unless you must. Even brands with fully custom storefronts frequently keep a platform checkout, because the conversion, compliance, and risk profile is so much better.<\/p>\n Budget for the decade, not the launch. Model ongoing engineering<\/a>, security, compliance, integration maintenance, and admin tooling across several years, then compare that with platform costs over the same period. Honest numbers change a lot of minds.<\/p>\n Plan for the team persisting. Who maintains this when the person who built it leaves? If you cannot answer confidently, you have found your biggest risk.<\/p>\n Start narrower than you think. Build the bit that is differentiated, and use existing infrastructure for everything else.<\/p>\n If you want to settle this argument internally, build the model properly. Most custom-build business cases compare a one-off build cost against a recurring subscription, which is not a comparison at all.<\/p>\n A defensible model runs several years and includes, on the custom side: the initial build; ongoing engineering to maintain and extend it; security patching and incident response; compliance work as tax, privacy, accessibility, and payment rules change; integration maintenance as third parties change their APIs; infrastructure and scaling; admin tooling your operations team needs; and the recruitment and retention cost of keeping commerce engineers.<\/p>\n On the platform side: subscription fees across the period; app subscriptions; and the custom development you would still do on top \u2014 apps, Functions, integrations, storefront work.<\/p>\n Then add two things most models omit. First, opportunity cost: what else would those engineers have built? Engineering spent on commodity commerce infrastructure produces nothing a customer notices. Second, conversion difference: if your checkout converts even slightly worse than Shopify’s, multiply that gap by your revenue across the whole period. That number alone frequently exceeds the entire platform fee.<\/p>\n Run that model honestly and the answer is usually clear. Run the naive version and custom always looks cheaper, which is why so many of these projects get approved and then quietly regretted.<\/p>\n Patterns repeat, and they are worth knowing before you commit.<\/p>\n The team changes.<\/strong> The engineers who built it move on, and their replacements inherit a system with no external documentation, no community, and no Stack Overflow answers. Velocity collapses. This is the single most common failure.<\/p>\n Version one takes far longer than planned.<\/strong> Commerce has more edge cases than anyone estimates \u2014 partial refunds, mixed carts, tax edge cases, address validation, failed payments, inventory races. Each is small; together they are most of the project.<\/p>\n The admin gets neglected.<\/strong> Customer-facing features get priority, so the operations team limps along with something half-finished, and the hidden cost lands on the people packing orders.<\/p>\n Integrations rot.<\/strong> Every connection you built is maintained by you. Third parties change APIs on their schedule, not yours.<\/p>\n Compliance surprises arrive.<\/strong> A tax change, a privacy regulation, an accessibility requirement. On a platform these arrive as updates; here they are unplanned projects.<\/p>\n Peak season exposes provisioning.<\/strong> The highest-traffic day of the year is the worst possible time to discover a capacity assumption was wrong.<\/p>\n None of these is inevitable with a strong team and honest planning. All of them are common enough that you should plan for them explicitly rather than assume you will be the exception.<\/p>\n<\/span>The costs people underestimate<\/span><\/h2>\n
<\/span>When building makes sense<\/span><\/h2>\n
<\/span>The middle path most brands miss<\/span><\/h2>\n
<\/span>A worked example: the build that got talked down<\/span><\/h2>\n
<\/span>If you do build, do it with open eyes<\/span><\/h2>\n
<\/span>The ten-year cost model nobody builds<\/span><\/h2>\n
<\/span>What actually goes wrong on custom builds<\/span><\/h2>\n
<\/span>Side by side<\/span><\/h2>\n