Every operations problem eventually produces the same meeting: someone found a SaaS product that mostly fits, someone else wants it built properly, and the decision defaults to whoever argues longest. Both sides are right somewhere. Off-the-shelf is the correct answer for most software a business touches, and custom is the correct answer for a specific, identifiable slice. This framework is how we help clients find which side of the line a given problem sits on.
Quick answer: Buy off-the-shelf when the process is standard and the tool’s workflow fits how you already work. Build custom when the workflow is your edge, when per-seat fees multiply badly across the team, or when people spend hours moving data between systems. Price both paths over five years, including subscriptions, workarounds, and integration time.
What counts as off-the-shelf, and what counts as custom?
It is a spectrum. Pure off-the-shelf is subscription software used as shipped. The middle is configurable platforms and no-code tools bent toward your process. Custom is software built for your workflow, owned by you. Most businesses should run a mix, and the framework question is never “which philosophy,” it is “which category does this specific problem belong in.”
When is off-the-shelf the right call?
When the process is a commodity. Email, accounting, payroll, documents, and standard CRM are problems shared by millions of businesses, and the products are mature because of it. Buy when a tool’s built-in workflow is one your team can adopt without contortions, when seat counts are small, and when the category is deep enough that switching vendors later is realistic. The discipline that makes buying work: adapt your process to the tool. Fighting an off-the-shelf product’s assumptions is the most expensive way to use one.
When does custom win?
- The workflow is your differentiator. If how you quote, schedule, or fulfill is why customers pick you, forcing it into a generic tool sands off the edge.
- The seat math turns against you. Forty dollars per user per month is nothing at 4 users and $24,000 a year at 50, forever.
- Integration duct tape has become a job. When someone’s actual role is copying data between systems that do not talk, the glue is worth building.
- The vendor is the risk: price hikes, feature removals, or a product sunset would hit a process you depend on.
- The tool fits 70 percent, and the missing 30 percent is where your money is made.
What do the paths cost over five years?
Run one honest table. The buy column: subscription times seats times sixty months, plus onboarding, plus the labor cost of workarounds and manual bridging, plus the price increases that come. The build column: the build cost, plus 15 to 25 percent per year for maintenance and improvement, plus hosting. A worked example: a 20-seat tool at $40 per seat is $48,000 over five years before workaround labor, against a $50,000 build that carries no seat fees at 20 users or 60. At 4 seats the same math lands the other way. The five-year frame is the whole trick, because sticker prices point one direction and totals frequently point the other.
Is there a middle path?
Often the best one. Keep the off-the-shelf systems that work and build the connective tissue: an integration that ends the re-keying, a customer-facing layer on top of a SaaS product’s API, or a custom module for the one workflow the market does not serve, with everything else bought. Replacing a single spreadsheet-driven workflow, which we covered in its own guide, is usually a first project in exactly this shape. Our Agile Embark approach is built around this: modular pieces where custom earns its cost, integrated with the tools that already work.
How do you run the decision?
Five questions, answered in writing:
- Is this process a differentiator or a commodity?
- What is the five-year total for each path, including seats, workarounds, and maintenance?
- How many systems must it talk to, and how well?
- How often does the process change, and who would change the software when it does?
- What happens if the vendor triples the price or sunsets the product?
Commodity, cheap totals, few integrations, stable process, low vendor risk: buy. The further the answers drift the other way, the stronger the build case. If you want a second opinion on a specific decision, send the details through the contact form and we will tell you which way we would go, including when the answer is the SaaS subscription.
Frequently asked questions
Isn’t custom software risky?
The risk lives in scoping and vendor selection more than in customness. Phased builds, a written spec, code you own, and documentation control it. Off-the-shelf carries its own risks, price increases, sunsets, and roadmaps that drift from your needs, they are someone else’s decisions.
Who maintains custom software long term?
Whoever you arrange: a maintenance agreement with the builder, another provider (which is why owning the code matters), or in-house staff. Budget 15 to 25 percent of the build cost per year. Custom software without a maintenance plan ages the same way an unmaintained website does.
What about no-code platforms?
A legitimate middle option, and often the right first move for an internal tool. The ceilings are complex logic, integration depth, record limits, and per-seat pricing that recreates the SaaS math. Plan the data export path on day one so graduating later is a project instead of a crisis.
Can we start with SaaS and switch to custom later?
Yes, and it is a sensible sequence: the SaaS years teach you exactly what the workflow needs. Protect the future switch by choosing tools with real data export and by keeping your process documentation current, since the export is the migration.
What happens if our developer disappears?
If you own the repository, the documentation, and the accounts, another competent developer picks it up. That is the test to apply before building: insist on code in your organization’s control and docs a stranger could follow. Vendor lock-in is a choice, on either path.
How do we scope a first custom project?
One workflow, smallest useful version. A short paid discovery produces the spec and a fixed quote, and the build replaces a single painful process end to end. Momentum and trust from a contained first project beat a two-year platform vision every time.