When open source beats building from scratch

Every time a client describes a system they need, we run the same early question: is there a production-grade open source project that already does 70% of this? If the answer is yes, the conversation changes. The question stops being should we build it and becomes should we adopt and extend it, or start from zero.

Most teams get that question wrong in two directions. Some refuse to touch OSS because their last experience was an abandoned GitHub repo with broken docs. Others adopt OSS that looks promising on a demo and discover six months later that nobody actually owns the deployment.

We've done this enough to have a short list of checks that keep us — and clients — out of both ditches.

What we look for before recommending an OSS base

• Active maintenance. A real release cadence, real maintainers, a real security track record. Commit velocity alone isn't enough — we look for how recent bugs were triaged and closed.
• A separable data model. Can your data leave the system without a rewrite? If not, you're marrying the software, not deploying it.
• A plugin or extension model that matches how you'll change the system. Some OSS is customized via plugins. Some is customized via forks. Some requires patching the core. Those three paths have wildly different long-term costs.
• Deployment stories we can see. If we can't find three production deployments that look like yours, we're underwriting risk the project has never tested.

Where OSS earns its place

For business operations: Odoo and ERPNext. For content and commerce: any of a dozen mature projects. These aren't "adopt and forget" decisions — they're "adopt, harden, and own." We build the CI/CD, we scope the security review, we add the custom features the business actually needs, and we stay on the hook for upgrades.

That last part is where most OSS engagements fail. The client was sold a fast start, got it, and then inherited a maintenance problem nobody scoped. Our OSS engagements ship with a support relationship from day one — not as an upsell, as the default.

When we steer clients away

Not every case is a fit. If your workflow is load-bearing differentiation — the thing customers pay you for — a fork is just a future bill. If regulation or data sovereignty requires line-by-line auditability, OSS inherits all of it. And if the project's license doesn't match your distribution model, no amount of engineering tidies that up.

The good news: you usually know which bucket you're in early. If the core of your business is "run a clinic well" or "run an ERP well," the OSS path is almost always cheaper and faster to a production-grade system than starting from scratch. If the core of your business is "we do X better than anyone," you probably want a custom build, or at minimum a custom core with OSS surrounding it.

Either way, the cost of picking badly is mostly time — and time is the thing we've spent the longest learning how to protect.