SaaS Costs Can Bite
Sure, the demo looks great. The sales rep demonstrates a dashboard that looks exactly like the one your ops team has been begging for. The rep knows your industry and hits the right pain points. The per-box pricing seems manageable at your current fleet size, so you sign on the dotted line. Two years later, you’ve doubled your fleet numbers. Now, that per-box fee is a line item on your P&L. You’re locked into a release cycle you don’t control, missing site-specific features your competitors have built, and you’re paying more every quarter. Your actual leverage over the product has gotten smaller not larger.
Time to talk about the ownership vs. SaaS debate.
The Math They Don’t Show at the Sales Demo
Fleet management software platforms typically cost anywhere between 5 and 25 per container per month, depending on the platform and the feature tier you choose. When you’ve only got 300 units on a 15 per-box plan, that’s 4,500 per month, which may be a reasonably modest software expense that’s not too difficult to absorb, assuming your cash flow is solid.
However, as you scale to 1,500 units, that “manageable” fee balloons to 22,500 per month, or 270,000 annually. Over five years, you’ve spent $1.35 million on a tool you don’t own.
The Deal Doesn’t Scale
A 2025 BCG analysis confirms that while buying is typically faster upfront, licensing fees and maintenance can add up over time. 65% of digital transformations fail because companies underestimate integration complexity and scalability demands. Furthermore, a 2024 joint study by KPMG and Ryder found that fleet owners frequently underestimate their total costs, with self-reported cost data running nearly 24 percentage points below third-party measurements. This is often the result of overlooked capital costs, administration fees, and other hidden levers. In fact, industry analysis suggests that per-unit pricing models often act as “structural taxes on ambition” that compound faster than the value they provide as the enterprise grows.
In other words, your leverage doesn’t scale with your spend. A 3,000 unit customer on a per-box SaaS platform is certainly a meaningful account for the vendor but you’re still only one customer among thousands. Any feature requests you have will go into the same queue as every other customer’s feature requests.
The Vendor Drives Your Roadmap
Your roadmap is the vendor’s roadmap and their roadmap reflects the average of what their customer base wants. Some vendors may be willing to develop a custom feature for you, but the cost will be exorbitant and vendors usually reserve the right to sell your specific feature in a future release. No defensibility for you.
Growth-stage fleet operators don’t fully model this financial reality when they sign an initial contract for a fleet management software platform.
What You Actually Own and What You’re Just Renting
There’s a big difference between what you use and what you actually own in a SaaS relationship. In most SaaS contracts you own the underlying data. But you don’t own the logic that processes and presents that data. You also don’t own the Integrations connecting your systems or the workflows built on top of the platform. Finally, you don’t own the institutional knowledge that’s embedded in the platform’s configuration.
And it really only matters when you decide to switch vendors. SaaS contracts often contain very narrow data portability provisions. You can export your records in a specified format, typically txt, CSV, TAB, or Excel, but all of the other configuration, integration, and operational logic built on top of the platform doesn’t come along. Instead, you have to start over from scratch.
Every year that you build your operations around a SaaS platform is another year your switching costs go up. It’s not because the vendor has done anything wrong. It’s just a natural effect of operational dependency. Your team understands how the current system works. Your workflows are built around specific features and limitations. And your reporting is calibrated to a specific built-in data model.
When you own the platform over your systems with your specific workflows, you invert the switching cost calculus. You’re no longer dependent on a vendor’s roadmap. You don’t pay a premium for features that the average customer doesn’t need. Any institutional knowledge embedded in the system belongs to you After all, you paid for it.
Custom-Built Versus Off-the-Shelf
The two concerns that typically frame arguments against custom development are the upfront cost and the ongoing maintenance burden.
It’s true that custom development can cost significantly more early on. A subscription to a SaaS solution almost always looks cheaper on paper. But, when you model the cost out over 5 years using your projected fleet size, that comparison looks a lot different. Suddenly, custom-built doesn’t look so expensive. At scale, per unit costs typically exceed the amortized cost of custom development within 18 to 30 months, if you plan to scale from 500 to 2500 units over 3 to 4 years. This alone tips the scale in favor of ownership vs. SaaS.
Ongoing Maintenance Is a Concern
And yes, the ongoing maintenance concern is real but addressable. Custom software requires ongoing development to adapt, add features, and keep up with Integration updates. But, what’s the alternative? What does the development cost look like relative to those alternatives?
Partnering vs. Hiring In-House
Agreeing to a retainer with a competent development partner provides the maintenance capacity without the fixed overhead of full-time in-house engineers. The ongoing cost is predictable and typically a fraction of what the per unit SaaS fee will become at scale. Partnering with a skilled development team becomes a much cheaper option than hiring and managing an in-house team or than scaling on an increasingly expensive SaaS platform.
One item that’s often overlooked in these types of calculations is the value of intellectual property that you’ll get from custom development. A custom dispatch, routing, and intelligence platform custom-built for your operation is a business asset. It contributes to the defensibility of your operational model and it’s something that would cost a competitor real time and money to replicate.
The Ownership Model in Practice
But let’s look at the practicalities of the ownership model in practice. It’s not necessarily a full custom-build from day one that makes sense for most operators. The right sequence looks something like this:
Start with what you already have. If you have a current SaaS platform that’s working adequately at your current scale, don’t tear it out. Build alongside it. Start by owning the unified data infrastructure that isn’t dependent on a single vendor’s platform.
- Identify the high value points where the off-the-shelf platform fails your specific operation.
- Identify workarounds or spreadsheets or other tools you maintain to cover cases the SaaS tool doesn’t.
- Identify manual work you perform to compensate for what the platform can’t do.
Working on those areas will create an immediate ROI.
Next, build incrementally on high-value targets. A complete rip-and-replace is unnecessary and inefficient. What you want to build toward is a core intelligence layer that you own. This layer connects to all of your existing systems and their data generators, such as sensors or other outputs. The intelligence layer ingests data in the various formats from each of your systems and then normalizes the data into more easily navigable data. The intelligence layer can then handle decision logic and pass of complex work to agentic AI, while the SaaS platform continues to serve as a departmental front end or as a system of record for specific functions.
By the time your fleet size makes your SaaS per unit cost really painful, you’ll already have a custom intelligence layer in place that can either fully replace the vendor platform or reduce your dependence on it.
Frequently Asked Questions (FAQ)
At what fleet size does the custom-build ROI case become compelling?
As a rough guide, operators above 500 units with clear plans to reach 1,500 or more should model the five-year comparison carefully before renewing a per-unit SaaS contract. Once you hit 1,500 units, the SaaS per-unit pricing model becomes unsustainable. For some operators with higher growth trajectories, the case becomes compelling at 300 to 400 units.
How do we avoid our own custom build becoming a maintenance burden we can’t manage?
Focus on architecture, not just code. Build on modern, maintainable architecture using standard APIs, documented integrations, and cloud infrastructure. This model is far easier to maintain and adapt than legacy custom systems built without those standards. Working with a development partner who follows these practices and provides ongoing maintenance support can make the maintenance burden both predictable and manageable.
What happens to the custom platform if we part ways with the development partner?
With the right contractual structure, you own everything: the source code, the documentation, the data architecture, and all credentials. A reputable partner builds with this in mind. The goal is to create something you could hand off to a new development team or maintain internally if you choose to. Insist on clear IP ownership provisions and full code access from the outset.
Can we run a custom platform and our existing SaaS platform simultaneously?
Yes, and this is the right approach during a transition. The custom layer connects to the SaaS platform and other in-house systems by way of APIs, other data connectors, or by data export. The custom layer builds on top of the existing data without interrupting operations.
How do we justify the upfront development investment to our board or investors?
The most effective approach is a phased model that delivers measurable ROI at each stage before committing to the next. A 90-day proof-of-value engagement focused on the highest-cost operational problem, typically either deadhead reduction, maintenance cost, or asset utilization, produces concrete numbers that support the business case for continued investment. You’re not asking for approval to build a platform; you’re showing a return on solving a specific problem, then building from there. Bridgera’s AI Readiness Assessment is a practical starting point for identifying where that first proof-of-value engagement should focus.
Sources referenced:
- BCG — Buy-and-Build Strategy Unlocks Greater Ops Tech Value
- KPMG / Ryder — Lease or Buy? Evaluating the Rising Cost of Truck Fleet Ownership (2024)
- Forrester — Comparing Total Cost of Ownership: SaaS vs. On-Premises Software (subscription required)
- Bridgera — AI Readiness Assessment
- Bridgera — Optimize Fleet Routing to Scale Profits
About Bridgera
Operational Intelligence. Production-Ready AI.
Bridgera partners with operations-heavy enterprises to move AI beyond pilots and into real production systems. Through AI consulting, specialized talent, and scalable platforms like Interscope AI™, Bridgera embeds intelligence directly into the operational workflows that power the business.
