Custom software for a growing business: when to build, when to buy, and how to keep what you own 

Build custom software when what you need doesn't exist off the shelf, or when the gap between two systems you already own is where the work piles up. If a proven tool does the job then buy it. Either way, you should own the code and the accounts from day one and someone should be accountable after go-live.

What actually counts as custom software for a small business?

Custom software is a program written for one business and its way of working, instead of a product sold to many businesses with the same features for everyone.

The word covers a wide range. At one end sits a large platform built from nothing, with its own login, database and screens. At the other end sits a small tool that does one job - a quoting screen, a stock-count app or a script that moves orders from your shop into your accounts. In my opinion most growing businesses need the small end far more often than the large end and very few need the platform they get quoted for.

People often mix up three things so let me separate them.

• Off-the-shelf software is rented with a subscription or licence and you adapt your work to the features the vendor built.
• Configured software is an off-the-shelf tool set up with your own fields, rules and workflows and little or no code.
• Custom software is code written for you so you decide what it does and you carry the cost of keeping it running.

Most good systems are a mix. Say your business runs accounting on a standard package and sales on a standard CRM and then one custom tool connects them and handles the one process nobody sells a product for.

When should a business build rather than buy?

Building makes sense when you've already tried buying or honestly ruled it out. Here are the situations where I think custom work can earn its cost.

The process is how you win

If the way you quote, schedule, inspect or deliver is the reason customers choose you then forcing it into a generic tool flattens it. A custom tool can protect the thing that makes you different and that's worth paying for.

No product fits without painful workarounds

Say you tried two or three tools and each one needed a spreadsheet beside it, a manual step every day or a rule your team must remember. When the workaround costs you more hours than the tool saves then the product doesn't fit.

The work piles up between your systems

In my opinion this is the most common case. Your shop, your accounts, your stock sheet and your messaging each work fine alone. The pain is a person exporting from one, cleaning the file and typing it into another every day. A small bridge removes that job and nobody sells it as a product because it is specific to your combination of tools.

Your volume or rules outgrew the tool

A tool that worked for ten orders a day may strain at a hundred. Or your pricing rules became so particular that the tool needs a long chain of manual overrides, and that's a sign to look at something built for your rules.

You are building a product to sell

If the software itself is the business then off the shelf isn't an option. In that case start with a small first version and test the idea before you build the full thing, and a separate article on MVPs covers how.

When is buying off the shelf the right answer for you?

More often than most software vendors will tell you, if I'm honest. My rule is to buy when most of these are true -

• Your need is common, and accounting, payroll, email, basic CRM, booking and invoicing all have good products at fair prices.
• A tool covers around eighty percent of what you need and a setting or a small habit can handle the rest.
• The vendor is established, publishes its prices and lets you export your data.
• You don't want to maintain anything and a subscription includes updates, security fixes and support that custom software won't give you for free.
• Speed matters because a subscription starts this week while a build starts in weeks and finishes in months.

Here's a test I like - write down the ten things your system must do and rank them. If a product handles your top seven without tricks then I'd buy it and live with the rest. If it fails on your top three then it's the wrong product.

The thing between the platforms you already own

Many quotes you receive are for a platform that replaces everything with a long list of modules, but what your business needs is often much smaller - the specific thing that sits between the platforms you already own.

A few examples will help you spot your own version.

• A form that captures a job on site and creates the record in your accounting package so nobody types it twice.
• A dashboard that reads from your sales tool and your accounts and shows you one list of overdue customers.
• A tool that takes supplier price files in different formats and turns them into one clean sheet.
• A booking screen that checks the calendar, the stock and the staff roster before it accepts a booking.

None of these needs a new platform and each one is small, quick to test and easy to explain. If a vendor proposes replacing everything when your problem is the gap between two things then ask them why and ask what happens to the data you already have as well.

How is a build scoped so it does not run to month fourteen?

A four-month build that reaches month fourteen is rarely caused by hard technology and almost always by a vague scope. A scope that holds up has these parts and I'd insist on every one of them.

1. Name your users in plain roles like the owner, the front desk, the accountant and the customer and give each role its own list of tasks.
2. Describe the first release in one paragraph and make sure it does one job well enough that people drop the old way for it.
3. List the data by saying where each piece of information comes from, who changes it and where it ends up. Define any term that two people might read differently, such as what counts as a sale or a completed job.
4. Write down what is out because a list of things the first release won't do is as useful as the list of things it will and it saves you arguments later.
5. Agree how change is handled so any new request after sign-off is written down, sized and approved with its time and cost stated before work starts.
6. Fix a review rhythm of short regular demos with a named person from your business who can say yes or no on the spot.

I think the named person matters most of all. Projects slow down when decisions wait for an owner who is busy elsewhere so pick one person with authority and give them time every week.

My advice is to release small and then add, because a first release that runs for one team for four weeks will teach you more than a plan that tries to serve everyone at once.

Who owns the code, the accounts and the data?

This question causes the most regret years later so settle it in writing before work begins. You should own three things.

The code

The source code should sit in a repository under an account in your name or your company's name and the contract should say that the finished work belongs to you. If the code lives only on the vendor's machines then you can't move to another team without their agreement.

The accounts

Hosting, domain names, databases, email services and app-store listings should be opened in your name with your email, with the vendor invited as a user. If they're opened in the vendor's name then you are renting your own system from them and I'd never accept that. Ask for admin access to every account and keep the sign-in details somewhere safe.

The data

The records your customers, staff and operations create belong to you. You should be able to export them in a common format at any time, without a fee and without a request that takes weeks. Check that backups exist, where they are kept and how a restore gets tested.

Documentation is part of ownership too and people forget this. A system that only its builder understands is a new version of the spreadsheet only one person understands and that's the problem you were trying to solve. So ask for a short written guide that explains how it is set up, how to deploy a change and what to do when something stops working.

What happens to your software after it goes live?

Go-live is the start of the system's life and not the end of the project. Software needs updates when libraries change, fixes when real use finds edge cases and small improvements as your business changes. Many builds fail quietly at this point because the team that built the system moves on and nobody is accountable.

You'll want these settled before the build starts.

• Who is your first contact when something stops working and how fast do they reply?
• How are bugs found in the first weeks handled and is there a defined period when fixes carry no extra charge?
• Who applies security updates and renews certificates and domains?
• How do you request a small improvement and how does it get sized and scheduled?
• What does it cost to keep the system running each month, including hosting and licences, and who pays those bills?
• If the vendor stops working with you, what do you receive so another team can carry on?

Make one person in your business accountable for the system too. A system with no internal owner drifts and before long your people go back to spreadsheets.

How do you decide between building and buying, step by step?

1. Write the problem down as a task a person does today, with the hours it takes and who does it.
2. Check whether a configured product removes most of that task and try it with your real data and not a demo.
3. If it doesn't then list the gap between your existing tools and the one thing that is missing.
4. Ask for a proposal for the smallest build that closes the gap, with a clear first release.
5. Compare that cost with the cost of the manual work over a couple of years, plus the cost of keeping the software running.
6. Check the ownership terms and the support plan before you look at prices.

If you're not sure which side your problem falls on then an outside view helps. Strategic advisory work often starts right here with a short review of the problem, the tools you own and your options before any money goes into a build. In my book, having someone who represents your business in technology decisions is often what separates a build that works from one that runs long.

What does custom software cost to keep running?

The build price is only one part of the cost and owners who plan for the running cost are rarely surprised later. Ask each vendor to list these items separately so that you can compare like with like -

• Hosting is the servers or cloud services where the system runs and it's usually a monthly bill from the provider.
• Licences and services are the paid tools your system depends on, such as email delivery, maps or payment gateways.
• Maintenance covers updates, security fixes and small repairs because software that is not maintained slowly stops working.
• Improvements are new features as your business changes and I'd plan a small allowance each year rather than a surprise.
• Internal time is the hours your own people spend on testing, training and answering questions.

Set these against what the manual work costs you today by counting the hours, the errors and the delays. Sometimes the comparison shows that a subscription is cheaper and sometimes that a small build pays for itself within a year or two. Either answer is useful, as long as you reach it with your own real figures.

Frequently asked

These are the questions owners most often ask before they start and you'll find short answers in the panel after this article. Hope this helps, and good luck with the build!