Build vs Buy vs Integrate: Logistics Tech Decisions for VP Supply Chains

Building a shipping platform is a tax on your product team. Buying one without an integration plan is a tax on your ops team. The answer is almost always hybrid, yet almost nobody sets it up that way.

Most VPs of Supply Chain don't realise they're making a technology decision until they're eight months into the wrong one.

It doesn't feel like a decision at the moment. The CEO hears about a brand that "built their own Ekart." The CTO has engineering bandwidth after the replatforming finishes. Ops is tired of chasing carriers on WhatsApp. Everyone nods. Someone puts together a 14-slide build proposal. The company moves.

Twelve months later, two of your best engineers are full-time on carrier API patches. Finance is still reconciling PODs manually. The feature roadmap for the storefront hasn't moved in two quarters. And nobody in the room is willing to say the word "sunk cost."

This is the most expensive, least-discussed decision in Indian retail operations:
Build vs Buy vs Integrate. And the reason it breaks so many teams is that it looks like a technology decision but is actually an org-design decision.

Let's take it apart.

Why Logistics Is Different from Every Other Build-vs-Buy Decision

The build-vs-buy debate exists in every SaaS category - CRM, analytics, HR, payments. In most of them, the math is tractable. You list your must-have features, estimate engineering costs, compare to vendor pricing, and make a call.

Logistics breaks that framework. Four things make it structurally different.

1. The Carrier Integration Treadmill.

A typical Indian brand at scale works with 8–15 carriers. Each carrier has its own API (and often two , one for manifesting and one for tracking). Those APIs change - new authentication schemes, new fields, deprecated endpoints, changed rate cards - roughly every 4–6 weeks across a portfolio. If you're building in-house, every single one of those changes lands on your engineering team as an unplanned ticket. You are not "building a logistics platform." You are signing up for a perpetual carrier maintenance contract.

2. Edge Case Density.

A single shipment can take 40+ states: manifested, picked up, misrouted, at hub, out for delivery, attempted, RTO initiated, undelivered cash-on-delivery, partial POD, weight discrepancy, lost-in-transit, etc. Each state has carrier-specific semantics. Ekart's "NDR" and Delhivery's "NDR" don't mean the same thing. Building a tracking layer that handles this cleanly is a 6–9 month project before you ship a single customer-facing feature.

3. Compliance Surface Area.

E-way bill. FASTag. State-wise COD remittance timelines. GST invoice formats. E-invoicing thresholds. A shipping platform built for India has to absorb these regulatory changes continuously, most of it unannounced, most of it urgent. Miss one, and you're blocked at toll plazas or sitting on frozen cash.

4. Domain Expertise Scarcity.

Engineers who both understand Indian logistics and can write the code to model it well are the rarest specialisation in B2B SaaS hiring. You are competing for them with Flipkart, Delhivery, and every platform incumbent. In most cities, the realistic hiring market is 20–40 people. You are not going to win that fight as a D2C brand.

None of these are reasons you can't build. Flipkart built Ekart. Amazon built ATS. Myntra has its own logistics stack. But all three built inside a company with 500+ engineers, a dedicated logistics product org, and a 10-year horizon.

The question is not whether building is possible. The question is whether it is rational for your company.

The True Cost of Building (What the Engineering Proposal Doesn't Say)

Every build proposal I have seen follows the same pattern. It estimates the cost of v1 and stops there.

But v1 is the cheapest part of building. The real cost is everything after launch, what I call the maintenance iceberg.

Here's the typical 3-year TCO for a mid-sized D2C brand (80,000–150,000 orders/month, 10 carriers):

3-year total cost of ownership. The maintenance layer is where most build estimates quietly explode.

Build path (in-house from scratch):

• Initial build: 4 engineers × 15 months × ₹28L fully-loaded = ₹1.4 Cr

• Year 2: carrier maintenance: 2 dedicated engineers = ₹56L

• Year 2: compliance & edge cases: 1 engineer = ₹28L

• Year 2: infra, monitoring, on-call: ₹30L

• Year 3: identical to Year 2 plus opportunity cost of features not shipped: ~₹1.2 Cr equivalent

• 3-year loaded TCO: ₹4.6–5.2 Cr - assuming nothing goes wrong.

Buy path (pure SaaS platform):

• Annual platform fee: ₹40–90L depending on volume

• Implementation: ₹15–25L one-time

• Ops overhead (no custom logic): ₹20L/yr absorbed in existing ops team

• 3-year loaded TCO: ₹1.8–3.2 Cr - linearly predictable.

Integrate path (platform + thin internal layer):

• Platform fee: ₹40–90L/yr

• Internal integration layer (1–1.5 engineers perpetually): ₹35–45L/yr

• 3-year loaded TCO: ₹2.5–3.8 Cr and you retain differentiation.

If you only look at Year 1, Build sometimes looks competitive. By Year 2, it is usually the most expensive option on the table. By Year 3, it is almost always the most expensive — and the most risky, because the people who built it have started leaving.

The Build Trap

Here is the failure mode we see most often.

A brand decides to build. The first twelve months go well. The team is motivated, the domain is interesting, v1 ships. Everybody celebrates.

Then the curve bends.

What "building our own" looks like from the engineering org's perspective.

By month 18, 60–70% of the original build team's capacity is being consumed by carrier maintenance, edge-case patches, and compliance updates. The product roadmap for the actual business - the storefront, the app, the personalisation engine, the features that differentiate your brand - has slowed to a crawl.

By month 24, two of the original four engineers have left. They were hired to build, not to maintain. The replacement hires take six months to ramp. The platform is now a black box owned by people who didn't design it.

By month 30, leadership is quietly discussing whether to migrate to a platform. But the data is locked up, the business logic is tangled, and the switching cost is now higher than the original build cost.

This is the Build Trap: the arc from "we can do this better ourselves" to "we cannot afford to unbuild this."

Brands that have genuinely succeeded at building in-house share three things: engineering orgs large enough that the logistics team is a footnote (typically 200+ engineers), shipment volumes above 5 million per year, and a board that treats logistics as a 10-year capability bet, not a cost centre. If you don't have all three, the Build Trap is the base-rate outcome.

The Buy Trap

The opposite extreme has its own failure mode, and it's almost as common.

A brand decides not to build. They buy a SaaS platform. Implementation is fast, 4–6 weeks. The ops team is happy. The first six months went well.

Then the plateau hits.

A pure-buy brand gets the same feature set every other brand on the platform gets. If your brand's differentiation is "we deliver faster than anyone in our category" or "our post-purchase experience is 2x better" - you cannot express that through a platform's generic config panel. Your carrier allocation logic, your customer comms, your exception handling rules, your returns flow , these are the specific places where brand experience lives. And they are the specific places a pure-buy setup flattens.

The Buy Trap is the arc from "fastest time to value" to "we look identical to our competitors." You've saved money on engineering and quietly surrendered the one thing you were trying to build a moat around.

Pure buy is the right answer for some companies. Sub-scale brands (< ₹30 Cr GMV) where logistics is genuinely commoditized. High-velocity, low-differentiation categories. Brands where the CEO's explicit strategy is to outsource ops. But for most ambitious D2C and omnichannel brands, pure buy is a false economy that shows up in your NPS scores 18 months later.

The Right Answer Is Almost Always the Third One

Between the two traps sits the answer that most brands eventually arrive at - but usually only after burning 12–18 months on one of the extremes first.

Call it Integrate. Or The Integration Layer. The structure looks like this:

Buy the network. Build the differentiation. Own the data.

Three clean layers:

Layer 1 — The Carrier Network (Buy).

This is the part nobody should build from scratch. 500+ carrier integrations, tracking state normalisation, POD capture, manifesting, compliance, API monitoring. This is pure infrastructure. Its value scales with the number of carriers already integrated. Buy it.

Layer 2 — The Business Logic Layer (Build).

This is where your differentiation lives. Your custom carrier allocation rules. Your category-specific exception handling. Your brand's customer communication voice. Your returns policy translated into workflow. Your analytics warehouse. This layer is where 1–1.5 engineers of perpetual investment pays back 10x - because it's the layer that actually makes your brand different.

Layer 3 — The Data & Decisioning Layer (Own).

Your shipment data, your cost data, your carrier performance data, all of it flows into your warehouse, not the platform's. This is non-negotiable. The day you want to switch platforms, consolidate multiple tools, or build ML-driven allocation, you need to own this data in your schema, not theirs.

Most VPs of Supply Chain who get this right didn't start here. They started in one of the two traps and migrated. The teams that avoid the detour are the ones who set up the three-layer architecture from Day 1, usually because their CTO has been burned on a build-everything decision at a previous company and won't make the same mistake twice.

The 8-Criterion Decision Framework

Here is the decision tree I walk every supply chain leader through. Eight questions. Answer honestly.

If you answered "Yes" to all eight, you are Flipkart or Amazon. Build.

If you answered "Yes" to the first six but hesitated on 7 or 8, the honest answer is: Integrate. You have the technical capacity to build, but the organisational and strategic conviction to sustain it isn't there. You will end up in the Build Trap.

If you answered "No" anywhere in the first five: Integrate is the only rational path. Buy the carrier network. Build the thin internal layer where your differentiation lives. Move on.

The CTO Conversation Guide

If you are a VP Supply Chain, this is the conversation you need to have with your CTO before any build decision is signed off. Five questions:

1. How much of our current engineering capacity is committed to roadmap items?

If the answer is > 80%, building logistics means delaying the storefront, the app, or the payments work. Be explicit about what gets cut.

2. Who is on-call for carrier API outages on Day 366?

If the answer is "the same people who built it," you have not planned for maintenance. You have planned for burnout.

3. What is our edge case discovery curve going to look like?

Ship volume n reveals edge cases at roughly the rate of log(n). At 100K shipments/month, you will find a new edge case every 3–4 days for the first year. Who is catching them?

4. How are we going to handle carrier onboarding at the 12-carrier mark?

Going from 5 to 10 carriers is 2x work. Going from 10 to 15 is roughly 3x, because carriers at the long tail have worse APIs. What happens at carrier 14?

5. What does the exit plan look like if we decide to migrate in Year 3?

If nobody can answer this clearly - data schema, business logic extraction, carrier contract portability - you are locking the company into a platform you built yourselves. That is worse than lock-in to a vendor, because you have no vendor to hold accountable.

A CTO who can answer all five is one I would trust to lead a build. A CTO who has not thought about any of them is one who should be politely redirected toward the Integrate path.

The Honest Patterns: What 48 Indian Retail Brands Chose

Across the 48-brand cohort in our 2026 India Retail Logistics Report, the split looks like this:

Roughly 77% of the cohort landed on Integrate. Among the ones who started on Build, 4 of 6 migrated within 36 months. Among the ones who started on pure Buy, most added an integration layer within 18 months once the commoditisation trap set in.

The pattern is almost comically consistent: the answer is the middle path, but you only see it clearly from the other side of a misstep.

If You're Reading This in the Middle of One of the Traps

Three situations, three practical answers.

"We already built v1. Should we throw it out?" Almost never. You should freeze further investment in Layer 1 (carrier integrations), port those onto a platform, and redirect your engineering effort into Layer 2 (business logic). Most brands find that 70% of what they thought was differentiated was actually just commodity carrier plumbing they shouldn't have built. The remaining 30% is your real moat, keep that.

"Our CTO insists on building because they've done it before." Then ask: at what scale, with how many engineers, over what horizon. CTOs who built at Flipkart, Myntra, or Amazon are describing a different company from yours. The experience transfers to the intuition but not to the resourcing.

"We're going public in 18 months." Integrate. Without exception. You cannot be in a distressed-eng-team situation in the 12 months before listing. Buy the network, build the layer, ship the other things investors actually ask about.

The Shift Most Supply Chain Leaders Need to Make

The instinct to build is almost always a leadership instinct - ownership, control, differentiation. Those instincts are right. The execution mistake is believing that owning the infrastructure and owning the advantage are the same thing.

They aren't.

Nobody competes on the quality of their carrier API parsers. They compete on the sharpness of their allocation logic, the speed of their exception handling, the elegance of their customer communication, and the intelligence in their returns flow. That is Layer 2. It deserves every engineer you can give it.

The layer underneath - the carrier network, the state normalisation, the compliance tax - buy it. Every hour your team spends there is an hour not spent on what makes your brand different.

Build the layer you compete on. Buy the layer everyone competes with.

That's the decision.

If you want to pressure-test this against how 48 Indian retail brands actually solved the Build vs Buy vs Integrate question

📖 India B2B Logistics Report 2026 — full benchmark data, TCO models, and architecture patterns: Download Now

📅 Book 20 minutes with our supply chain team to walk through the 8-criterion framework for your specific operation.

🔗 See how ClickPost fits the Integrate layer

About this article: Based on architecture patterns and total cost models observed across 48 Indian retail brands (GMV ₹30 Cr – ₹1,200 Cr), in-depth conversations with supply chain and engineering leaders, and three years of carrier integration data from the ClickPost platform.

Source:

• Walmart Inc., Annual Report (discussion of Flipkart and Ekart operations). Walmart Investor Relations: 
  

• Gartner, "Build, Buy, or Both: Evaluating the Right Path for Enterprise Software." Gartner Research:

• Delhivery Limited, Red Herring Prospectus, filed with SEBI, 2021–22. Public filing accessible via SEBI's public document portal:

• Amazon.com, Inc., Annual Reports and public disclosures regarding Amazon Transportation Services (ATS) and Amazon Logistics operations.

• McKinsey & Company, research on SaaS and platform business economics, available through McKinsey Insights: