The custom system that ate the company
A mid-sized logistics company built their own dispatch system in 2019. At the time, the decision made sense: the available off-the-shelf options didn't handle their specific routing logic, the budget was tight, and they had a contractor who "knew the business." Six months later they had a working system. The contractor moved on.
By 2023, the system was a liability. It ran on a server in a closet. Nobody fully understood the codebase. Every change required rehiring the original contractor or finding someone willing to work on a framework that was already three versions behind. The "custom advantage" they'd built in 2019 — the routing logic — had been commoditized by every major TMS vendor by 2021.
They spent $40,000 migrating to a standard platform. The lesson wasn't that building is always wrong. It's that the decision deserves a framework, not a gut call.
The framework
The build vs buy decision has five dimensions. Work through them in order — each one can short-circuit the rest.
1. Does this differentiate you competitively?
This is the threshold question. If the software capability is directly tied to why customers choose you over competitors, building is worth serious consideration. If it's infrastructure — payroll, invoicing, inventory, CRM — it almost certainly isn't.
A freight broker whose proprietary matching algorithm is their core product should build and own that algorithm. Their invoicing process should run on an off-the-shelf tool.
Most internal ops software — the tools that move data between people and departments — doesn't differentiate anything. It just runs the business. The bar for building should be high.
2. Does a viable off-the-shelf option exist?
"Viable" means: covers at least 80% of your requirements without customization, has a track record with companies of your size and industry, and has a support model you can actually access.
Before writing any spec, do an honest evaluation of the market. Spend two weeks demoing three options. The category of software you think doesn't exist often does exist — you just haven't looked recently. The SaaS market for vertical ops software has expanded dramatically in the last five years.
If no viable option exists, build becomes a stronger candidate. But be honest about the evaluation — "it doesn't do things exactly the way we do them" is different from "it doesn't exist."
3. What does ongoing maintenance actually cost?
This is where build decisions consistently underestimate. The cost of building is the cost of the initial development plus the cost of maintaining and evolving that software indefinitely.
A rough model: ongoing maintenance of a custom system typically costs 15–25% of the initial build cost per year. A system that cost $80,000 to build costs $12,000–$20,000 per year to keep current — security patches, dependency updates, new browser compatibility, changes to external APIs it integrates with.
That maintenance cost doesn't go away when the original developer leaves. It often goes up, because the new person has to learn a codebase they didn't write.
Compare that to an off-the-shelf subscription that covers maintenance, updates, and support in the license fee. The economics look different when you include the full lifetime cost.
4. How specialized are your requirements — really?
Every company thinks their requirements are unique. Often they're not. They're standard requirements implemented in a non-standard way because "that's how we've always done it."
Before deciding your requirements are too specialized for off-the-shelf, ask: is this requirement genuinely unique to our business model, or is it unique to the way we currently operate — which might itself be worth changing?
Sometimes the right answer isn't "build something that matches our current process." It's "buy the best tool and adapt our process to it." The latter is often faster and cheaper, and sometimes forces useful process improvements.
5. Do you have the capacity to own this?
Owning a custom system requires sustained technical capacity: someone who can make changes, respond to outages, handle upgrades. Not just to build it, but forever.
If you're a 30-person company without a dedicated engineering team, you're not in a position to own a complex custom system long-term. You can build something simple. You can commission a well-scoped project and manage it externally. But the ongoing maintenance question has to be answered before you start, not after the contractor delivers the initial version.
The decision in practice
We use a simple scoring system with clients facing this decision:
| Factor | Build | Buy |
|---|---|---|
| Core competitive differentiator | Yes | No |
| Off-the-shelf option exists | No | Yes |
| Team can maintain ongoing | Yes | No |
| Requirements truly unique | Yes | No |
| 3-year total cost lower | Verify | Usually yes |
Three or more "Build" answers is a genuine signal to build. Fewer than that, the default should be buy.
When buy is wrong
Buy is the wrong answer in these cases:
The vendor lock-in risk is material. If the platform could price you out or shut down and you'd have no viable exit, the dependency is dangerous. This is especially relevant for core data stores — make sure you can export your data in a useful format before signing a multi-year contract.
The integration surface is too complex. If connecting the off-the-shelf tool to your existing systems requires more custom development than building the tool itself, the economics flip.
Regulatory requirements exclude cloud options. Some industries and jurisdictions — finance, health, certain government sectors — have data residency or compliance requirements that rule out most SaaS options. That's a genuine constraint, not a preference.
The vendor roadmap is misaligned. A tool that does 80% of what you need today but is actively moving away from your use case is a liability. The 80% will erode, and you'll be dependent on something that serves you less over time.
The practical recommendation
For most Argentine SMEs evaluating ops software: buy, configure aggressively, and customize only what generates clear ROI. The cost of building and maintaining custom software is systematically underestimated in initial decisions and systematically overestimated in retrospect — because by the time the true cost is visible, the decision is already made.
The right time to evaluate this seriously is before the first line of code is written or the first demo is scheduled — not after six months of a project that's going over budget.
Working through a build-vs-buy decision and want a second opinion on the tradeoffs? We do this kind of scoping regularly.