Decision guide

Custom software or off-the-shelf: how to decide

A plain way to decide whether to buy a product, configure a platform or build your own. Including the cases where building is the wrong answer.

For any business8 min read

The short answer

Buy when your process is the usual one. Build when the process is how you win, or when no product does the main job. Configure a platform when you need something between the two. A business often does all three, for different parts of what it runs. Custom software is also called bespoke software, and off-the-shelf software is also called packaged software.

The three choices
Compare Off-the-shelf product Configurable platform Custom-built software
What it is Software made for many businesses and used as it comes. A product or framework that you set up and extend to your rules. Software written for your business and yours alone.
Time to start Shortest. You sign up and begin. Weeks to set up to your rules, once you know them. Longest. You start with a brief and see it work in stages.
Fit to how you work You change your process to suit it. Good where your rules differ in detail but not in kind. As close as you are willing to specify and pay for.
Control of changes The vendor's roadmap decides. Shared: settings are yours, new features may not be. Yours, if you own the code and have people to change it.
Cost pattern Lower at the start, rising with users and modules. Moderate to start, then steady. Highest to start, then the cost of looking after it.
Main risk Outgrowing it, and being unable to leave. Paying for flexibility you do not use. Building the wrong thing, or depending on one developer.

Questions that decide it

Answer these in writing before you ask anyone for a quote.

  1. Is the process how you compete?

    If a rival could use the same product and run the same process, there is little reason to build it. If the process is what makes you better or different, it may be worth owning.

  2. Does a product do the main job already?

    Try it with your own cases, not the vendor's. If it does the main job with a few workarounds, buy it. If the workarounds are the main job, it does not fit.

  3. Can you write down what it must do?

    If you cannot describe it in plain sentences to someone outside your company, a developer cannot build it either. Start with a discovery step, not code.

  4. Will anyone own it after launch?

    Software is not finished when it goes live. Somebody has to decide what changes, pay for hosting and fix what breaks.

  5. What happens if you want to leave?

    With a product, can you export your data? With custom work, do you own the code, the data and the accounts it runs in?

Signs that your choice has stopped working

Both choices go wrong in recognisable ways. The limitations of off-the-shelf software usually show first as workarounds.

Signs that off-the-shelf has stopped fitting

  • Staff keep a spreadsheet beside the product to do what it cannot.
  • The same information is typed into two or three systems.
  • Each change you ask for waits for the vendor, or is refused.
  • You pay for modules nobody opens, or hit a price step each time you grow.
  • You cannot get your data out in a form another system can read.

Signs that custom software is a bad idea

  • You cannot yet describe what it should do.
  • The process changes every few weeks, so what you specify is out of date by the time it is built.
  • A product fits most of the job and you only dislike its price.
  • Nobody in the company will own it once the developers have gone.
  • You want it only because the idea of owning your own system is attractive.

How to cut the risk of building

The risk in custom work can be reduced by how you start, and by what you insist on owning.

  • Start with the smallest useful piece. Something real people use soon teaches more than a long specification.
  • See working software often. Ask for something you can click through every couple of weeks, not a report on progress.
  • Use standard parts. Common frameworks, standard sign-in and well-known payment services keep the work readable by the next developer.
  • Write down the decisions. Ask for documentation of how it is built and how it is run, so that you are not hostage to one person's memory.
  • Plan the handover. Know who will fix a fault on the day after launch, and what that costs.

What to own, in writing

The contract decides who owns what. Ask that you own the source code, your data, the domain names and the cloud and app store accounts, and that the passwords and keys are in your company's name, not the developer's.

What it costs over time

A price at the start is only part of the cost. Whatever you choose, plan for the same lines.

The lines to plan for
Line Off-the-shelf Custom-built
Getting started Set-up, training and moving your data in. Discovery, design, building, testing and moving your data in.
Running it Licence or subscription, and any fees by user or by use. Hosting, monitoring, backups, licences for the parts you use.
Keeping it working Usually in the price, until a price step. Fixes, security updates and changes in phones, browsers and payment services. Plan for it every year.
Changing it Whatever the vendor will do, when it will do it. Whatever you can specify and fund, when your team can do it.
Leaving Export of your data, if the vendor allows it. Handing the code and accounts to another team.

What is different in Kenya

Custom software development in Kenya has the same trade-offs as anywhere, with a few local ones to weigh before you decide.

  • Payments: if your customers pay by M-Pesa, check that it is built into a product, not an add-on that one developer maintains.
  • Tax: invoices have to meet the rules of the Kenya Revenue Authority. Ask how a product keeps up when those rules change.
  • Personal data: the Data Protection Act, 2019 applies to what you store about customers and staff, whoever built the system.
  • Support: ask who you can reach in your own time zone, and whether they can visit when something is wrong.

Do both

The choice is rarely all or nothing. A sensible shape for many businesses is to buy the parts that every business has, such as email, accounting or payroll, and to build only the part that is yours. The two are joined by their APIs, so that what is entered once appears where it is needed.

Keep reading

Common questions

What is the difference between custom and off-the-shelf software?

Off-the-shelf software is made for many businesses and used as it comes. Custom software is written for one business to fit how it works. A configurable platform sits between them: you set it up and extend it to your rules.

Is custom software more expensive than off-the-shelf software?

Usually more to start and less to grow, but not always. A product is cheaper at the start and often rises with users and modules. Custom work costs more at the start, then the cost of looking after it. Compare the total over several years, not the first invoice.

When should a business build custom software?

When the process is how the business wins, when no product does the main job, or when the workarounds around a product cost more than a system built for the work. Not before you can describe what it must do.

Who owns custom software?

The contract decides. Ask in writing that your company owns the source code, the data, the domain names and the cloud and app store accounts, and that the passwords are in its name.

How long does custom software take to build?

It depends on what it has to do, and any date given before the scope is known is a guess. A fair plan starts with a short discovery step, builds the smallest useful piece first and lets you use it before the rest is finished.

Can we start with a product and build later?

Yes, and it is often the sensible order. Choose a product that lets you export your data, then build only what the product cannot do, joining the two through their APIs.

Not sure which way fits?

Tell us what the system has to do and what you use today. We will say plainly whether to buy, configure or build, even when the answer is not to build with us.

Talk to us about your system