Skip to content

Build or subscribe? When custom software beats another tool

Most software should be bought. Some should be built, and often the best answer is to connect what you have. How to tell which is which, and how to make sure you own what you pay for.

Software5 min readSoventia Ltd

Most of the software a company needs should be bought. Email, accounting, payroll and video calls are the same job everywhere, someone has built them well, and building your own would be a waste. But some tools get bought by default and then quietly shape the business around their limits. The useful question is not "build or buy?" in general. It is which of your tools are which.

Subscribe to the common, build the difference

A subscription is the right call when the job is standard, the tool does it well, and the way you do it is not what customers choose you for. You get a product that improves without you, support, and someone else carrying the maintenance.

Building starts to make sense when the process is yours: the way you quote, schedule, inspect, onboard or report is part of why customers pick you. A standard tool makes you work like everyone else who uses it. For most things that is fine. For the few that make you different, it is a cost that never shows up on an invoice.

Signs a tool has stopped fitting

  • A spreadsheet lives next to it. People export, fix and re-import, because the tool cannot hold how the work really goes.
  • Someone copies data by hand from one system to another, every day or every week.
  • Seats are paid for people who need one screen: a field worker who only logs a job, a manager who only reads one report.
  • The team has learned its workarounds by heart, and new staff have to be taught them.
  • You have asked the vendor for the same feature for years.

None of these on its own means you should build. Several of them together usually mean the tool is costing more than its price.

The third option: connect what you have

Often the best answer is neither. Keep the tools that do their job and build the small piece between them: an integration that moves the data, a simple internal app on top of two systems, or an automation that replaces the copying. Many business tools have an API for exactly this.

It is less work than replacing a system, it keeps the parts that already work, and it removes the manual step that caused the problem in the first place.

  1. Is this process part of how you win work, or what makes you different?
  2. Is it the same job in every company, like payroll, email or accounting?
  3. Would a standard tool cover most of it, if it were set up well?
  4. Do people keep a spreadsheet next to the tool to do the real work?
  5. Does someone copy data by hand between this tool and another one?
  6. Are you paying for full seats for people who only need one screen?
  7. Is there someone who would own a custom tool once it is built?

Answer a few questions

  • Subscribe
  • Connect
  • Build

The answers are only a lean, not a verdict. They work for any tool and any budget.

Which way does your tool lean? Seven questions, no numbers. It is a lean, not a verdict.

Compare the whole cost, both ways

A fair comparison runs over the years you expect to use the thing, not the first one.

On the subscription side: the seats now and as the team grows, price changes you do not control, the time spent on workarounds, and what it would take to leave. Check whether you can export all of your data in a format another system can read.

On the build side: the build itself, hosting, and a yearly budget for keeping it running, because software that nobody maintains slowly breaks. And someone in the company who owns it: decides what changes, and knows who to call.

If that owner does not exist, a subscription is usually the safer choice, whatever the numbers say.

Who owns what you build

This is the part people check too late. In UK law, a computer program is a literary work under the Copyright, Designs and Patents Act 1988, and the author is the first owner of the copyright. If an employee writes it as part of their job, the employer owns it. If a contractor or an agency writes it, the contractor owns it, unless the copyright is assigned to you. And an assignment of copyright is not effective unless it is in writing and signed by or on behalf of the person assigning it.

So "we paid for it" is not the same as "we own it". Read the ownership clause before you sign: what passes to you, when, and what the developer keeps. Under our terms, the copyright in what we build for you passes to you on payment, and the accounts it runs on are in your name from the start.

Sources

  1. Copyright, Designs and Patents Act 1988, section 3 (literary works include computer programs) legislation.gov.uk
  2. Copyright, Designs and Patents Act 1988, section 11 (first ownership of copyright) legislation.gov.uk
  3. Copyright, Designs and Patents Act 1988, section 90 (assignment must be in writing) legislation.gov.uk

Start with a 30-minute call.

Bring the idea as it is. We ask questions, tell you how we see it, and if we are not the right fit, we say so and point you to someone who is.