Most supply chain teams run the build-versus-buy comparison backwards. They collect licensing quotes from three vendors, put them in a spreadsheet, pick the middle one, and never seriously price the alternative. The build option gets dismissed early — not because anyone costed it, but because “custom software” sounds expensive and slow, and the RFP calendar is already moving.

That instinct is sometimes right. But without a baseline for how much it costs to build a web app that does the same job, the licensing number has nothing to sit against. A $180,000 five-year SaaS commitment isn’t expensive or cheap in the abstract. It’s expensive or cheap relative to something.

This piece lays out both sides of that comparison the way a US shipper or 3PL should actually run it — over five years, with the costs that don’t appear in either the vendor quote or the development estimate.

The five-year frame is the only honest one

There’s decent evidence that these investment decisions don’t hold. In a Gartner survey of 151 supply chain leaders conducted between November and December 2025, 72% reported having to revisit final approvals for network decisions at least once, and more than half went back three or more times — with satisfaction in the eventual outcome dropping accordingly. Gartner’s analysis points at a specific cause: business cases that model one-time and ongoing costs but leave out the variable costs of operating through constant friction.

That’s precisely the failure mode in a build-versus-buy call. The decision gets made on a first-year number, the costs that weren’t modelled show up in year two, and the whole thing gets reopened.

A one-year comparison always favours SaaS. You pay a subscription, you go live in eight weeks, and there’s no capital outlay. A build, by contrast, front-loads almost everything: discovery, design, development, testing, deployment, all before a single user logs in.

Flip to year five and the shape inverts. Subscription costs compound and typically escalate at renewal. Build costs drop to a maintenance line after go-live. Whichever way the decision goes, a three-to-five-year window is the shortest one that shows you the real trade — and it happens to match how long most supply chain systems actually stay in service.

What enterprise SaaS actually costs over five years

The subscription line is the part everyone budgets for. It’s rarely the part that causes problems.

Licensing. Enterprise supply chain platforms — WMS, TMS, supplier collaboration portals — are usually priced per user, per site, per order volume, or some blend. Per-seat pricing has an awkward property in logistics: your user count scales with headcount, not with value delivered. Add a shift at a DC and your software bill goes up, even though the software isn’t doing anything new.

Implementation. Budget this as a serious number, not a rounding error. Enterprise WMS and TMS implementations commonly run a meaningful multiple of first-year licensing once you include configuration, testing, and go-live support.

Integration. Your platform has to talk to an ERP, a carrier network, EDI trading partners, and probably a handful of customer-specific portals. Some of that is covered by standard connectors. The rest is custom work, billed by the vendor or a systems integrator, and it recurs — every time a trading partner changes a spec, someone gets paid to update the mapping.

Customisation you can’t keep. This is the cost nobody models. You pay to configure the platform around your process, and then you pay again at every major version upgrade to carry those configurations forward. Over five years and two or three upgrade cycles, that’s a standing tax on having a process that differs from the vendor’s assumptions.

Escalation. Multi-year contracts typically include annual uplifts. A 5% escalator on a $60,000 subscription adds roughly $16,000 across five years before a single new user is added. Renewal after the initial term is where leverage genuinely shifts, and it doesn’t shift toward you.

The exit cost. Ask what it takes to get your historical data out in a usable form. The answer is often “we can export that” followed by a quote.

What a custom build actually costs over five years

The development estimate is the part everyone budgets for here too. And again, it’s not the part that causes problems.

Mid-complexity web applications — internal portals, operational dashboards, supplier-facing tools — generally land in the $50,000 to $150,000 range when built by Eastern European or LATAM engineering teams. A US or Western European agency doing the same scope will typically cost two to three times that. For a supply chain application with real-time tracking, several system integrations, and role-based access across internal and external users, plan toward the upper half of that band rather than the lower.

Then add what comes after:

• Maintenance: roughly 15–25% of the original build cost annually, covering security patches, dependency updates, and bug fixes
• Infrastructure and hosting: anywhere from a few hundred to several thousand dollars a month depending on transaction volume
• New features: the ones you’ll want in year two once operations has actually used the thing
• Compliance work: SOC 2, and more if you handle payment or customs data

Taken together, three-to-five-year total cost of ownership commonly runs 2.5 to 3.5 times the initial build. A $120,000 application is realistically a $300,000–$420,000 commitment over that window. Any comparison that puts $120,000 against a five-year subscription total is not a comparison — it’s a rounding error waiting to become a budget variance.

The crossover point, with numbers

Take a mid-size shipper needing a supplier portal: PO visibility, ASN submission, document upload, exception flagging, ERP integration, roughly 40 internal users and 200 external supplier users.

SaaS path. Licensing at $45,000/year for internal seats, with external supplier access priced separately or bundled depending on vendor. Implementation and integration in year one. Annual escalation at 5%. Two upgrade cycles requiring reconfiguration. Five-year total lands somewhere in the $400,000–$550,000 range. ⚠ [VERIFY: replace with a real anonymised quote range or a cited industry pricing benchmark.]

Build path. Roughly $130,000 to build with a nearshore or Eastern European team. Maintenance at 20% annually. Hosting at $1,200/month. One meaningful feature expansion in year three. Five-year total in the $350,000–$450,000 range.

The two paths land close enough that cost alone doesn’t decide it. What decides it are the variables that move the crossover.

Four factors that move the crossover

Process fit. If your workflow matches how the vendor built the product, buy. Configuration is cheap and you inherit a roadmap you didn’t pay to build. If your operation does something genuinely differentiated — a consolidation model, a customer-specific SLA structure, a cross-dock sequence competitors don’t run — configuration becomes fighting the product, and you pay for that fight annually.

User count trajectory. Per-seat SaaS punishes growth. If you’re adding sites, adding shifts, or onboarding hundreds of suppliers, licensing scales with your headcount while a custom application’s cost stays roughly flat. Run the licensing model against your three-year headcount plan, not today’s.

Integration surface. The more systems the tool must touch, the more the two paths converge — because in a build, integration is most of the work, and in SaaS, integration is most of what you pay a systems integrator for.

Whether the software is the differentiator. If the tool is how you win business — a customer-facing visibility portal that shows up in RFPs — a bought platform gives you exactly what your competitors can also buy. If it’s a back-office function nobody outside the building sees, buy it and move on.

Three situations where buying is obviously the right call

The four factors above cut both ways, but there are cases where the analysis is short and the answer is buy. Recognising them early saves you a procurement cycle.

When the vendor carries a regulatory burden you’d otherwise carry yourself. Customs filing, hazmat classification, denied-party screening, FDA or DOT reporting — this is functionality where the requirement changes without asking you, and where being wrong is a fine rather than a bug. A commercial vendor amortises the cost of tracking those changes across their entire customer base. You’d be funding a compliance function to serve one company. That maths never works.

When the vendor’s roadmap outruns anything you’d fund. Established WMS and TMS vendors reinvest a substantial share of revenue into engineering, and you get the output of that for a subscription. Ask honestly what your organisation would approve annually to keep a self-built equivalent current. If the honest answer is “whatever’s left after the operational budget” — and for most shippers it is — you’re comparing a funded roadmap against an unfunded one, and the build will quietly fall behind by year three.

When the horizon is shorter than the payback. A build only pays off over a multi-year window. If you’re mid-acquisition, running a network redesign, or serving a contract that renews in 24 months, you may not own the problem long enough to reach the crossover. Buy something you can turn off, and revisit when the picture settles.

There’s a fourth case that’s less about economics: if your team has no capacity to own software after launch — no product owner, no one accountable for the backlog — a build will decay regardless of how well it was scoped. Custom software isn’t a capital purchase; it’s an ongoing commitment to maintain something. Organisations that can’t staff that commitment should buy, even when the five-year numbers favour building.

Most shippers end up hybrid, and that’s usually correct

The framing is misleading in practice. Very few organisations go all-build or all-buy.

The pattern that holds up: buy the commodity layer — WMS, TMS, ERP, the systems where the industry has converged on a standard and the vendor’s roadmap is worth more than your customisation. Build the thin layer on top where your process is actually distinctive, and where an off-the-shelf product would either force you into someone else’s workflow or leave you paying for reconfiguration at every upgrade.

That layer is usually a web application: a dashboard aggregating data from three systems, a portal your customers log into, an exception-management tool your planners use daily. It’s the part where a $100,000–$150,000 build sits on top of a licensed platform and does the 15% of the job the platform was never going to do well.

Before you sign either one

Four questions worth answering while both options are still live:

1. Ask the SaaS vendor for a five-year total, including implementation, integration, escalation, and one major upgrade. Not the annual subscription. The total.

2. Ask the development partner for a three-year TCO forecast, not a build quote. A vendor who can’t produce one hasn’t thought past invoicing you for the build.

3. Price the exit on both sides. Data extraction from the SaaS platform, and handover documentation and code ownership on the build. Get code ownership in writing, effective at final payment.

4. Run the licensing model against your three-year headcount plan. Per-seat pricing that looks reasonable at 40 users often doesn’t at 120.

Neither path is inherently cheaper. What’s expensive is deciding without pricing the alternative — and that’s the version of this decision most supply chain teams are still making.