Software for your business · Updated October 20, 2026

Should I buy off-the-shelf software or build custom software?

Updated October 20, 2026

Buy off the shelf for work every business does the same way, like email, payroll or accounting. Build only when the off-the-shelf tools still leave your team re-typing, keeping side spreadsheets or working around the software every week, or when the process itself is how you win jobs. Configure first, then decide.

Buy for the work every business does the same way; build for the work that sets you apart

If the job is the same at your business as at everyone else's, buy the software. If the job is how you win work, or the tools on the market only fit it after hours of workarounds every week, that is the case for building.

UK government guidance draws the same line for its own departments. Buying may be better when "there is a commercially available way to meet most of your user needs" and you "do not need a high level of customisation or bespoke changes." Building fits a need that is "unique or rare," and it "gives you more control over your requirements and flexibility to adapt your processes."

Buy off the shelf: Email, payroll, accounting, phones, calendars and most scheduling. Thousands of businesses need these to work the same way, and the vendor keeps them updated.; Right when the tool does the job after you set it up, and your team stops working around it.
Build custom: The process that makes you different, or the gap between three tools your team bridges by hand: estimates, dispatch rules, proposals, a calculator for customers.; Right when the workarounds cost hours every week and no tool on the market removes them.

Even the US government is told to buy first. Federal law requires every executive agency to make sure, "to the maximum extent practicable," that its requirements "are defined so that commercial services or commercial products" can be bought to meet them. Only when nothing commercial fits does the law point to other existing items. A small business has more reason, not less, to start with what is already on the market.

Configure the tool you already pay for before you customize it or replace it

Before deciding anything, spend an afternoon with the settings of the software you have: custom fields, job and invoice templates, user roles, automations, and the list of apps it connects to. Some complaints about a tool turn out to be a setting nobody turned on.

Configuration and customization are different things. Configuration uses the options the vendor built in, and is generally kept when the vendor updates the product. Customization changes the product itself, through paid add-on development, scripts or a developer working inside it. UK government guidance warns that "even small modifications to OTS software can remove most of the benefits of using it," and says to "consider configuring your software settings instead so there is still product support when suppliers release new versions." Customizations can also "restrict you from upgrading or removing them in future."

If a setting fixes it, you may be done, at no extra cost.
If it needs customizing a tool you rent, weigh that against building the one missing piece separately. A customized product is harder to update, and the work leaves with the subscription if you switch.
If no setting, add-on or connection closes the gap, you have found the part worth building.

Measure the cost of staying

Count the hours your team spends working around the software for two weeks

Ask each person to note every time they type the same information into a second place, open a spreadsheet the software should have replaced, or chase something the system should have told them. Two weeks is usually enough to see the pattern.

The subscription is only part of what a tool costs. Re-typing, side spreadsheets and phone calls to find out where a job stands are paid hours too, and they grow with every hire. That count is the number to weigh a build against.

For example

A six-person service company keeps job details in its field app, re-types each finished job into its accounting software, and tracks parts per truck in a spreadsheet. The office manager logs about 40 minutes a day on re-typing and the techs about 10 minutes each on the parts sheet. That is roughly 7 hours a week, about 350 hours a year, spent moving information between tools that do not talk to each other. The first question is whether a connection between the two apps removes most of it. If none does, those hours are the case for building the missing piece.

Price the per-user bill at the size you plan to be, not the size you are

Before you sign, work out what the plan costs with the team you expect in two or three years. Many field service and CRM tools are priced by the number of people who log in.

Jobber, for example, defines a user as "anyone who accesses your account at the office or in the field to view or manage the team's schedule." Its plans are priced by team size, from 1 user up to 15, with custom pricing above that, and each user added costs more every month. A tool that is cheap for three people can be the biggest software bill in the business at fifteen. Per-user pricing can be fair. Run the number before you commit.

Check how you get your data out before you put it in

Before you move your customer list into any tool, find its export page in the help center and check three things: which plans can export, which user roles can, and what comes out.

The answers vary more than most owners expect. Jobber's help center says "Client exporting is available on select plans," that "Only admin users are able to import and export clients," and that a CSV export holds "up to 1500 rows" at a time, with larger lists split across files. That is a clear, workable process, and it is also a reminder that leaving a tool is a project you should know the shape of on day one.

Customers and contacts, with notes and tags.
Jobs, quotes and invoices, with dates and line items.
Files and photos attached to jobs.

If you decide to build

Get the copyright in the code assigned to your business in a signed document

If an outside developer builds it, put a clause in the contract that assigns the copyright in the code they write for you to the business, signed by both sides. Expect the developer to keep their own reusable components and license them to you; get that in writing too.

Paying for software does not make it yours. The US Copyright Office explains that "Ordinarily, the author is the person or persons who actually created the work." Commissioned work counts as a work made for hire only in nine listed categories, and only "if the parties expressly agree in a written instrument signed by them." Software is not one of the nine by name. "If a work fails to satisfy any of these requirements, it is not a work made for hire." An assignment avoids the question. The same rule applies to a website, covered in full on the page about who should own your website and domain.

Try a working version on your own data before you commit to the whole build

Ask to see the riskiest part working, on a copy of your real records, before you agree to build everything. Then build in stages, each one something your team can use, and run each beside the old tool until it matches.

UK government guidance tells its own teams not to commit to a technology before they "have tried out different options during alpha," the stage for testing ideas. A demo on sample data proves the screens look right. A trial on your own records shows whether the edge cases, the odd jobs and the messy customer names survive.

Make sure someone can fix it on a bad day, in writing

Before the build starts, settle who answers when it breaks, how fast, who holds the code and the hosting accounts, and what happens if the developer stops working with you.

UK government guidance treats being able to support a technology as a condition for buying it, and for a build asks its teams to consider "how you will manage the technology once the specialist team has built it." It also wants contracts explicit about "the ownership of intellectual property involved in the delivery of a technology service." For a small business that comes down to four things in the contract:

The code in a repository the business can sign in to.
The hosting and database in accounts the business owns, or a documented way to move them.
Backups you can reach without the developer.
A response time for problems that stop your team working.