Off-the-shelf or custom software? Six questions to help decide

Off-the-shelf software is the right choice when your work runs the way that software assumes it does; custom software is right when the workflow that sets you apart fits no ready-made product. For most companies the answer is a mix — a packaged product for standard work such as accounting, and a custom piece for the process that makes the business distinct. The most reliable way to decide is to answer the six questions below honestly.

We are a studio that builds custom software. Even so, this is not an article telling you to have everything built. One of the most common pieces of advice we give in a first conversation is that a job can be done perfectly well with an existing product.

The difference between off-the-shelf and custom software

Off-the-shelf software is a product made for a need that thousands of companies share. It is usually paid for by subscription. You start straight away, and maintenance and updates sit with the vendor. In return, you adapt to the way the product expects you to work.

Custom software is designed around how your business actually runs. The screens, rules and reports come from your needs. In return, there is a development process, an initial investment and an ongoing need for maintenance.

	Off-the-shelf	Custom
Getting started	Fast	Needs a development process
Fit	You adapt to the software	The software adapts to you
Cost structure	Ongoing fee per user or per month	Initial investment plus maintenance
Changes	Depend on the vendor’s roadmap	Your decision
Data and ownership	On the vendor’s platform	Entirely yours, if you wish
Integration	As far as the vendor allows	As far as you need

The table does not declare a winner. Your answers to the questions below do.

Off-the-shelf or custom software: six questions

Work through them in order, and note your answers down. They are, broadly, what we discuss in a first conversation.

Question 1: Is this the process that sets you apart?

Accounting, payroll, email, calendars — these are roughly the same in every company. Building custom software for them is usually reinventing the wheel. Packaged products in these areas carry years of refinement, and the vendor adapts them when regulations change.

Some processes, though, are the company: the way you prepare quotes, how you plan production, a particular follow-up rhythm you keep with customers. If what distinguishes you from competitors lives in that workflow, forcing it into a template everyone uses can erase the advantage.

As a rule: packaged products for standard work, custom software for the work that differentiates you.

Question 2: How far are you bending the product?

Teams using a packaged product often show the same symptoms:

Spreadsheets kept in parallel with the software
A field used to hold something it was never meant to hold
Manual exports and merges done every month
Onboarding that includes “we don’t use this screen for that, just skip it”

If you recognise these, the product covers only part of your work. People fill the gap by hand — and that effort, not the subscription fee, is the real cost.

Question 3: Which systems does it need to talk to?

Software is often valued by how well it talks to everything else: accounting, payments, shipping, CRM, messaging. Packaged products usually cover the common integrations, but they may not connect to a regional system you rely on or a tool specific to your sector.

Ask two things:

Does the product have an API — does it let other software talk to it?
Can it notify another system when something happens (a new order, a payment, a sign-up)? The technical term is a webhook.

If both answers are yes, the sensible route is often to keep the product and write a small custom integration on top of it. That is the third option — not all or nothing.

Question 4: Where does your data sit, and who owns it?

With packaged products, your data is held on the vendor’s platform. For most work that is fine. Think carefully, though, if:

Your data must be kept in a particular country or on your own server
Your sector has strict rules on data retention and access — under GDPR, for instance, or Türkiye’s equivalent, KVKK
It is unclear whether you could take all your data with you if you switched vendors

With custom software, these decisions are yours. We deploy the software we build in the cloud or on the client’s own server, depending on the need, and on request the source code is handed over at delivery.

Question 5: How much will you have paid in five years?

Cost comparisons are often done wrongly: the packaged product’s monthly fee is set beside the first quote for custom work. The right comparison is the total cost of ownership over a fixed period.

On the off-the-shelf side, include:

Per-user fees that grow with the team
Features locked behind a higher tier
The human effort that covers what the product leaves out
Fees for extra integration tools

On the custom side, include:

Initial development
Hosting and infrastructure
Monthly maintenance, security updates and development for new needs
The time your team needs to settle into the new system

Which side weighs more depends entirely on your situation. We do not quote figures here, because a general number would mislead. Scope is settled in a first conversation and followed by a written proposal. We explain what to look for in one in how to read a software proposal.

Question 6: Might you sell this software one day?

Sometimes software started for internal use turns into a product other companies with the same problem would pay for. If that is the intention, the decision changes from the start: you are no longer designing an internal tool but a SaaS product. A multi-tenant structure, subscription plans and billing must be planned in. We walk through that path in building a SaaS product from an MVP.

How to read your answers

Roughly:

Standard process, few integrations, no data constraints: start with off-the-shelf.
Standard process, but the systems don’t talk to each other: keep the products and add a custom integration or automation between them.
The process differentiates you and you keep bending the product: custom software is worth considering.
You want to sell the software to others: start small, as a SaaS product built on MVP thinking.

A mixed setup is perfectly normal. In many companies the right answer is packaged products for standard work, joined by a custom layer that brings them into one admin panel.

A concrete example: quotes and order tracking

Picture a ten-person wholesale company. It uses a packaged accounting program and a packaged CRM. Quotes, however, are built in spreadsheets and emailed out. Once accepted, a sales rep re-enters the quote as an order, then re-enters it again in accounting.

Answering the six questions for this company:

Differentiating process: the way it quotes is its own, with discount rules that vary by customer.
Bending: the CRM’s quoting module cannot handle those rules, so it sits unused and spreadsheets fill in.
Integration: both the accounting program and the CRM have APIs.
Data: no special constraints.
Total cost: the real burden is the same information typed in three times, and the errors that creep in.
Intent to sell: none.

The answer is neither “build everything” nor “leave everything as it is”. Accounting and the CRM stay. Between them goes a small quoting module that knows the company’s discount rules, and an accepted quote flows automatically into the CRM and accounting. Custom software appears only where the work differs. Some connection jobs like this can be handled with an automation set-up rather than a full piece of software.

Frequently asked questions

Is custom software always more expensive?

In initial investment, usually yes. Over several years, though — especially as the user count grows and people are covering for the product’s gaps — the picture can change. Compare total cost of ownership, not the first invoice.

Will we lose data moving from packaged to custom software?

You should not. Moving data from spreadsheets or the old system into the new structure is part of the migration plan, and we include it in the development scope.

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

Yes — and it is often the route we recommend. Working with a packaged product shows you clearly what is missing, so the scope of the custom software can be set far more precisely.

Who maintains custom software?

The team that built it, or another team of your choosing. We offer monthly maintenance after delivery. Because the source code and documentation can be handed over to you, you are free to move maintenance elsewhere.

If you would like to think through which route suits your situation, see our custom software and SaaS page or write to us. If we think a packaged product will do, we will say so plainly.