Custom Software vs Off-the-Shelf: A Decision Framework for SMBs

Every growing business hits this question eventually: keep paying for tools that almost fit, or build something that actually does? The custom software vs off the shelf decision comes up in most of our first conversations with SMB owners, and neither option wins by default. Off-the-shelf is cheaper to start with, custom software is cheaper to live with - sometimes. This post lays out the framework we use to figure out which side of that line a business sits on, and how to scope a build without betting the company on it.

Custom software vs off-the-shelf: the real trade-off

The build vs buy software decision is usually framed as a price comparison. It is really a comparison of cost shapes.

Off-the-shelf tools have a low entry cost and a compounding ongoing cost. You pay per seat, per month, forever. The price scales with headcount, vendors raise prices over time, and most businesses accumulate tools faster than they retire them. Industry benchmarks published in 2025 put SaaS spend somewhere between roughly $3,500 and $5,600 per employee per year, depending on the survey and company size - for a 30-person company, a six-figure annual line item that mostly renews on autopilot.

Custom software inverts the shape. The cost is concentrated up front in the build, and the ongoing cost is comparatively flat: hosting, monitoring, and maintenance. There are no per-seat fees, so the cost per user falls as you grow instead of rising.

Both options also carry hidden costs that rarely make it into the spreadsheet. For off-the-shelf, it is the manual work that glues tools together, the workarounds for missing features, and the licenses nobody uses. For custom, it is maintenance, dependency on whoever built it, and the risk of scoping the wrong thing. The useful comparison is not subscription price against build quote, it is total cost of ownership over a realistic horizon. More on that below.

When off-the-shelf is the right call

We recommend off-the-shelf more often than you might expect from a company that builds custom software. Buying usually wins when:

• The problem is a commodity. Accounting, payroll, email, calendars, basic CRM, document storage. These are solved problems, and vendors solve them better than a custom build ever will.
• Your process is not stable yet. If you are still figuring out how your sales or operations workflow should work, a cheap monthly subscription is a better experiment than a fixed build.
• The tool covers 90 percent or more of what you need, and the remaining 10 percent is an inconvenience rather than a cost.
• The workflow is not what makes your business different. If your competitors run the same process the same way, there is little return on owning it.
• Switching costs are low. If you can export your data and leave within a week, the lock-in risk that makes subscriptions dangerous mostly disappears.

The pattern behind all of these: buy where the software is generic, and reserve building for where your business is not.

Triggers we see in SMB clients: when custom starts paying for itself

On the other side, a fairly consistent set of triggers shows up in the SMBs we work with when the math starts favoring a custom build:

• Per-seat fees have crossed a threshold. A tool at 50 euros per user per month is trivial for 5 people and 30,000 euros a year for 50 people, before the next price increase.
• People have become the integration layer. Staff export CSVs from one system, clean them up, and import them into another. That manual glue work is payroll spent on data plumbing.
• The workflow is the business. When how you quote, schedule, dispatch, or fulfill is precisely what wins you customers, renting a generic version of it caps your advantage.
• Your data is scattered. Answering a basic question like "which customers are profitable" requires opening four tools and a spreadsheet.
• The vendor cannot handle your edge case, and that edge case is central to how you operate. Years of workarounds usually cost more than solving it properly once.
• Reporting or compliance needs have outgrown what exports bolted onto someone else's data model can do.

One trigger alone rarely justifies a build. Two or three together, sustained over a year or more, usually do.

The spreadsheet ceiling: signs your team has outgrown its tools

A special case worth its own section, because it is the most common starting point in our SMB work: the business-critical spreadsheet. Spreadsheets are excellent prototypes and terrible systems. The warning signs are familiar:

• One person owns the file, and things stop when they are on holiday.
• Concurrent editing causes conflicts, or people keep personal copies "to be safe".
• There is no audit trail, so nobody knows who changed a number or when.
• Formulas have grown so intertwined that nobody dares to touch them.
• Data is copied between sheets by hand, and errors surface weeks later in invoices or stock counts.

The spreadsheet to web app move is often the most clearly justified custom build there is, because the scope is already defined: the spreadsheet documents the data model, the workflow, and the reports your team actually uses. Rebuilding it as a small web application adds what a spreadsheet cannot provide - validation at the point of entry, user permissions, change history, integrations, and dashboards that update themselves. These projects also tend to be small, because you are building one workflow for one team, and the requirements are sitting in front of you.

The middle path: extending off-the-shelf tools with custom integrations

Build vs buy is not binary. The option SMBs most often overlook is keeping the off-the-shelf tools that work and building only the missing connective tissue:

• Integrations that move data between systems automatically, replacing manual exports.
• An automation layer that handles the repetitive steps in a workflow, including AI agents where the volume genuinely justifies them.
• A thin custom interface on top of an off-the-shelf backend, so staff get a screen built for their job instead of a generic admin panel.
• A reporting layer that pulls from several tools into one dashboard.

This path keeps proven systems as the system of record while removing the manual work around them. It is usually the cheapest first step, and it defers the bigger build vs buy decision until you have real usage data. Sometimes the integration layer is all you ever need. Sometimes it confirms the core tool is the bottleneck, and now you know exactly which parts the replacement must cover.

Total cost of ownership over 3-5 years

This is where the bespoke software vs off the shelf comparison gets concrete. Model both options over three to five years, because that is where the cost shapes diverge.

For off-the-shelf, count:

• Subscription fees across all tools involved in the workflow, multiplied by realistic headcount growth and historical vendor price increases.
• The labor cost of manual workarounds and data transfer between tools.
• License waste. Several 2025 industry reports estimate that roughly half of paid SaaS licenses go unused or underused, which matches what we see in SMB tool audits.
• Migration cost when you eventually outgrow the tool anyway.

For custom, count:

• The build. On custom software development cost, published 2025 and 2026 price guides put simple business applications roughly in the $30,000 to $80,000 range, with mid-complexity internal tools often running $80,000 to $200,000. Agency rates in Europe typically run somewhere between 25 and 50 euros per hour in Central and Eastern Europe and 80 to 100 euros or more in Western Europe, which is why the same scope gets quoted at very different totals.
• Hosting and infrastructure, which for typical SMB internal tools is a small monthly amount, not a subscription per seat.
• Maintenance. A common industry rule of thumb puts ongoing maintenance at around 15 to 20 percent of the initial build cost per year. Treat anyone who quotes a build with zero maintenance as a red flag.

Then compare the curves, not the first-year totals. Off-the-shelf usually wins year one. The interesting question is which line is on top in year four, and by how much. Our fixed-price proposals spell out the expected savings in exactly these terms so the decision rests on numbers rather than preference.

Ownership, lock-in, and exit: what you control with each option

Cost is only half the framework. The other half is control. With off-the-shelf, you control configuration and your subscription. You do not control the roadmap, the pricing, the data model, or the vendor's future. Price increases arrive whether or not the product improved for you, features get deprecated, vendors get acquired or shut down, and the quality of data export varies from clean CSVs to effectively hostage data.

With custom software, you control the code, the data, and the infrastructure. The risk shifts: now you depend on whoever maintains it. That risk is manageable if you insist on the right deliverables - full ownership of the codebase, infrastructure under your own accounts, and written documentation of the architecture. In our projects, complete codebase ownership and a written technical roadmap are part of the handover, not an extra. A build that leaves you unable to switch suppliers has traded one lock-in for another, and we wrote about how those shortcuts accumulate in our post on technical debt.

How to scope a custom build without overcommitting

The biggest failure mode in custom software is not bad code, it is bad scope: a year-long project to replace everything at once. To avoid it:

• Pick one workflow with a measurable cost. Not "our operations", but "quote creation takes two hours and produces errors".
• Fix the scope and the price before the build starts. Open-ended hourly engagements put all the scoping risk on you.
• Time-box it. Our MVP sprints run four to six weeks from kickoff to deployed product: week one for strategy and architecture, weeks two and three for the build, week four for deployment and handover. The price is fixed up front, and the deliverables are a deployed product, the complete codebase, the infrastructure setup, and a written technical roadmap for what comes next.
• Ship to real users before extending. The second phase should be scoped from what the first phase taught you, not from the original wishlist.

A small, fixed-scope first build answers the build vs buy question with evidence instead of projections. If the tool removes the cost it was meant to remove, extending it is an easy decision. If it does not, you have lost weeks, not years. Examples of how this plays out are in our case studies.

Where we fit

We are transfactor, a senior team based in Bucharest working with European and global clients. For SMBs we build custom software, workflow automation including AI agents where the math works, and data dashboards - typically replacing spreadsheets and legacy tools. Engagements start with a free assessment workshop, and proposals are fixed-price with the expected savings spelled out, so the build vs buy comparison is done on paper before anything is built. We are ISO 9001:2015 and ISO/IEC 27001:2022 certified.

If you are weighing custom software vs off the shelf for a specific workflow, the details of how we work with SMBs are at /smbs.