Is custom software only for large enterprises?

No—that idea dates from when custom meant an eighteen-month platform project. A single workflow, scoped tightly, is a much smaller thing. Companies with 20 to 250 employees build custom internal systems precisely because they are big enough to feel the friction and small enough that no enterprise vendor designs for them.

What happens if the company that builds it disappears?

A fair question, and you should ask it of any partner. Protect yourself the same way you would with any vendor: you own the code and the documentation, it is built on boring mainstream technology, and another competent firm could pick it up. The risk profile is not worse than a niche SaaS vendor going under—which also happens.

Can we start with off-the-shelf and go custom later?

Often the smartest path. Run a product for a year, learn where it genuinely cannot follow your process, then build the specific layer that is missing. You will scope the custom work with evidence instead of guesses.

How do we compare costs honestly?

Take the product’s subscription across five years at your expected headcount, add implementation and consulting, add the fully-loaded hours your people spend on workarounds, and add the errors that reach customers. Compare that to a fixed build proposal plus hosting and maintenance. The honest comparison surprises people in both directions.

What about the hybrid approach?

It is the most common right answer for operational companies: off-the-shelf for the system of record and commodity functions, custom for the operational layer in between—the approvals, exceptions, portals, and dashboards that define how you actually work.

Making the call

Custom software vs. off-the-shelf: which is right for an operational company?

Off-the-shelf wins when the function is standard and a product fits most of it. Custom wins when the workflow is how your operation competes and every product you evaluate forces it into the same generic shape. Neither answer is morally superior—both are expensive when chosen for the wrong job.

This page compares the two on the dimensions that actually decide outcomes: fit, cost over years, control, and change. (If you want the broader strategy question—including when to simply configure what you already own—see build vs. buy.)

Side by side, on what matters

Dimension	Off-the-shelf	Custom
Fit to your process	Built for the average company. Your process bends to the product; edge cases become workarounds.	Built around the way you work. Your rules, approvals, and exceptions are the design, not an afterthought.
Speed to start	Fast when the fit is real—weeks. Slow when it is not—implementation projects stretch for quarters.	Slower to first version, but scoped to one workflow, the first working release arrives in a defined build window.
Cost shape	Predictable subscription that grows with every seat, every year, forever—plus the labor of workarounds nobody budgets for.	Higher upfront build cost, then modest hosting and maintenance. No per-seat tax as you grow.
Change over time	You get what the vendor’s roadmap gives the average customer. Feature requests join a queue.	Changes when your operation changes, because you own it and decide what it does next.
Data and integration	Integration depends on the vendor’s API and their interest in connecting to your ERP.	Built to sit between your systems from day one—ERP, inboxes, portals, spreadsheets.
Maintenance burden	The vendor maintains the product; you maintain the spreadsheets and side processes that make up the gap.	Someone must own the system—your partner or your team. A small, well-scoped build keeps this honest.

When off-the-shelf is the better choice

Choose the product when the function is a solved problem: accounting, payroll, email, document signing, a conventional CRM. Thousands of companies run these the same way, and the products reflect decades of refinement you cannot rebuild economically. Choose it when you are still learning the process—a year on a serviceable tool teaches you what the real requirements are, cheaply. And choose it when a product genuinely covers the workflow, quirks included. Some categories, like shipping or tax calculation, are so standardized that building them yourself would be pure waste.

When custom is the better choice

Choose custom when the evaluation keeps failing the same way: every product demos well, and every product breaks on your pricing rules, your approval chains, your exception handling, or your ERP integration. That pattern is the market telling you the workflow is distinctive. It is common in the exact places operational companies compete—quote and order workflows, customer and vendor portals, operational reporting that spans systems no vendor connects.

Custom also wins on cost more often than people expect. Per-seat pricing across a growing team, plus implementation, plus the hours your people spend on workarounds, adds up to a quiet build-sized number over a few years—with nothing owned at the end of it. For the cost framework, see what drives custom software cost.

Common mistakes on both sides

Evaluating products on feature lists instead of on your three hardest workflows. Demos show the happy path; your operation lives in the exceptions.
Believing the demo of the configuration, not the shipped product. “That can be configured” sometimes means “a consultant can build that for you.”
Going custom for standard functions because the team wants to build. Rebuilding what a mature product does is ego, not strategy.
Comparing a custom build to this year’s subscription instead of the five-year total, including workaround labor.
Treating it as one decision for the whole company. It is a per-workflow decision, and the honest answer is usually a mix.

Frequently asked questions

: No—that idea dates from when custom meant an eighteen-month platform project. A single workflow, scoped tightly, is a much smaller thing. Companies with 20 to 250 employees build custom internal systems precisely because they are big enough to feel the friction and small enough that no enterprise vendor designs for them.
: A fair question, and you should ask it of any partner. Protect yourself the same way you would with any vendor: you own the code and the documentation, it is built on boring mainstream technology, and another competent firm could pick it up. The risk profile is not worse than a niche SaaS vendor going under—which also happens.
: Often the smartest path. Run a product for a year, learn where it genuinely cannot follow your process, then build the specific layer that is missing. You will scope the custom work with evidence instead of guesses.
: Take the product’s subscription across five years at your expected headcount, add implementation and consulting, add the fully-loaded hours your people spend on workarounds, and add the errors that reach customers. Compare that to a fixed build proposal plus hosting and maintenance. The honest comparison surprises people in both directions.
: It is the most common right answer for operational companies: off-the-shelf for the system of record and commodity functions, custom for the operational layer in between—the approvals, exceptions, portals, and dashboards that define how you actually work.

Keep investigating

Evaluating products that almost fit?

Bring the three workflows every demo breaks on. A Workflow Review will tell you whether the gap is worth building for.

Book a Workflow Review Explore Common Operational Problems