Build versus buy gets argued as though it were one decision with one answer, usually decided by whoever is in the room. An engineering-led team builds. A finance-led team buys. Both then discover the cost two years later.
It is not one decision. It is six or seven separate decisions, and the correct answer genuinely differs by category. Here is each one, with the numbers that should drive it.
First, the two cost figures everybody gets wrong
Buying costs more than the subscription. Total cost of ownership work on business software consistently lands at roughly 2.5 to 4 times the licence fee across a multi-year horizon, once you include implementation, integration, data migration, internal admin time and training. A tool quoted at ₹50,000 a month is a ₹15 to ₹24 lakh a year commitment in practice.
Building costs more than the build. Ongoing maintenance runs about 15 to 25 percent of the original build cost per year, every year, indefinitely. A ₹20 lakh build carries a ₹3 to ₹5 lakh annual tail before anyone asks for a new feature. And the real cost is not cash, it is that the engineer maintaining it is not building something your customers would notice.
Compare those two honestly and most build-versus-buy arguments resolve themselves. The ones that do not are the interesting ones.
Platform: buy, essentially always
Your storefront, cart, checkout, payments and tax handling should be bought. This is the clearest call in the stack.
The reason is not difficulty, it is churn. Payment regulations change. Tax rules change. Fraud patterns change. Browser and privacy behaviour changes. Agent-driven checkout protocols are arriving right now and will keep moving, which we cover in how AI agents will buy. A bought platform absorbs all of that as part of the subscription. A built one hands you every change as a project.
On tiering: Shopify Plus runs around ₹1.65 lakh a month in India, and the honest threshold for it is somewhere above ₹15 to ₹20 crore a year in GMV, where checkout customisation, API limits and support response start to matter commercially. Below that, the standard plan with sound architecture outperforms both Plus and anything custom.
The one legitimate exception is a business whose buying experience is genuinely unlike retail - complex configurators, quote-based B2B flows, heavy made-to-order personalisation. Even then the right move is usually a bought platform with a built front end over it, not a built platform.
OMS: buy the core, build the rules
Order management is where this gets interesting, because the answer is split.
The core is commodity: capturing orders from every channel, holding their state, exposing them to everything downstream. Buy that. Several vendors do it well and none of them lose you a customer.
The rules are not commodity. Which warehouse serves which order, how a split shipment is decided, what happens when a decoration step fails quality check, how a made-to-order item moves through approval - that logic frequently is your operation. Off-the-shelf order management assumes a flow, and if your flow is genuinely different you will spend more fighting the assumption than you would have spent encoding your own.
So the pattern that works: bought system of record, built orchestration layer on top. You get the vendor's reliability on state and your own logic where it earns something. This is the architecture behind our own FlowCore work, which exists precisely because decorated and made-to-order goods break standard order management.
PIM: buy, and later than you think
Product information management is an unambiguous buy. There is nothing proprietary about storing attributes, managing variants and syndicating to channels, and there are mature tools at every price point.
The real question is timing. Below a few hundred SKUs across two or three channels, a well-governed spreadsheet plus your platform's native fields genuinely works. PIM earns its cost when attribute counts explode, when channel-specific requirements diverge, or when agent and marketplace feeds demand structured data you do not currently hold. Buy it when that pain is real, not when a roadmap says you should have one.
WMS and fulfilment: buy, or do not run it yourself
Warehouse management is deep, physical, and brutally unforgiving of a half-built system. Buy, or use a 3PL whose systems you integrate with.
The one thing worth building here is the layer that reconciles what the warehouse says against what your order system says, because that is where the discrepancies live and no vendor owns both sides. The mismatch problem is covered in why your ecommerce numbers never match.
Apps: buy, but ruthlessly, and stop at a point
Apps are the category where buying goes wrong by accumulation rather than by any single bad decision. Average paid apps sit around ₹2,500 to ₹5,000 a month each, most merchants run six to eight, and stores past roughly sixteen apps measure meaningfully worse on page performance.
Each individual purchase is defensible. The portfolio is not. Past a certain point the right move is not another app, it is integration architecture - the argument in stop adding Shopify apps.
Integration: build, almost always
This is the inversion. Integration is the category where buying is usually wrong.
iPaaS platforms run $10,000 to $40,000 in implementation plus $500 to $3,000 a month, with 20 to 40 percent in costs that do not appear in the quote and 15 to 25 percent annual maintenance on top. For a handful of connections, that is a large bill for something a competent team builds and owns.
More importantly, your integration layer encodes how your business actually works - your field mappings, your reconciliation rules, your exception handling. That is institutional knowledge, and renting it means you cannot read it. Buy the queue, buy the hosting, buy the monitoring. Build the logic.
The qualifier: this assumes you can staff it. A team of one developer who might leave should not own the layer every system depends on.
The three questions for everything else
When the category is not on this list, these settle it.
Does it differentiate us in a way a customer would notice? Not "is it important" - everything is important. Would a customer feel the difference between your version and the market standard? If not, buy.
Can we still staff it in three years? Not can we build it. Can we maintain it after the person who wrote it has moved on, during a sale week, at 11pm. Honest answer only.
Is there a vendor already doing ninety percent of it? If yes, buy and build the last ten percent around it. The ninety percent is where all the unglamorous edge cases live, and you will rediscover every one of them.
Two or more nos on the first two questions, or a yes on the third, means buy. That is most things.
The two patterns that reliably lose
Across every category above, the same two mistakes cost the most.
Building a commodity because the team wanted to. Someone estimates a week for a feature a vendor sells for ₹8,000 a month, and the estimate is even honest for version one. Then come the edge cases, the compliance change, the person who wrote it leaving, and three years of a 15 to 25 percent maintenance tail on something no customer will ever notice. The tell is an argument that focuses on how straightforward the build is. Difficulty was never the question.
Buying your differentiator because it was faster. Rarer and more expensive. A brand whose advantage is a genuinely unusual fulfilment model adopts a tool that assumes a standard one, spends eighteen months working around the assumption, and ends up with an operation shaped by a vendor's defaults. The advantage does not disappear dramatically. It erodes, because every exception now costs something to handle.
The first mistake wastes money. The second one slowly removes the reason customers chose you. If you have limited attention for this decision, spend it on the second.
Keep the decision reversible
The thing that makes build versus buy feel high stakes is the fear of being stuck. Mostly you are not stuck - unless you let a vendor own your data model.
Keep your canonical records yours. Define your own order, customer and product entities and treat vendor schemas as something you map to, not something you adopt. Build and buy against clean interfaces. Do that and a bought tool is swappable and a built one is retirable, and the decision you make this quarter is a two-year commitment rather than a permanent one.
The companies that get badly trapped are not the ones that chose wrong. They are the ones that let a single vendor become the definition of their business, and then found that leaving meant rebuilding everything at once.
If you want this mapped against your actual stack - what to buy, what to build, and what you are currently paying for twice - book an architecture review. We come back with the category-by-category call and the ownership cost for each.
