Custom software vs off the shelf in one question
Custom software vs off the shelf comes down to one question: does this job work the same way in every company, or only in yours? If it works the same everywhere, buy a product and change your process to fit it. Build when the software's main job is what sets you apart, or when every product forces a daily workaround you can't remove by changing how you work. Often the answer is both.
Custom software, also called bespoke software, is built for one company. Off-the-shelf software is one product sold to many, usually as a monthly subscription. This guide is for owners and operations leads at UK and EU companies of 10 to 200 people who are deciding which one to pay for.
We build custom internal software for a living, and our usual advice is still to buy. A product that does the job well enough this week beats a perfect system you wait months for and then have to look after. The rest of this guide is about the exceptions, and how to tell whether you're one of them.
Buy when the job works the same everywhere
Buy software for any job your competitors do the same way you do. Accounting, payroll, email, a sales pipeline, a helpdesk: your customers never see how you run these, and running them differently wins you nothing.
The software writer Martin Fowler calls this utility software, as opposed to strategic software that supports what sets a business apart. His advice for utility jobs is to buy the package and change your business process to match it. He also warns that people tend to count too many projects as strategic.
Changing your process feels like losing. It's often a free upgrade. A product sold to thousands of companies carries their lessons. It has the approval step you forgot, the report your accountant will ask for, and the permission you'll need the day someone leaves.
Buying also moves work off your desk. The vendor runs the servers, installs the security fixes and ships improvements you didn't have to specify. You get working software in days rather than a project.
The costly mistake sits halfway between the two paths: buying a product, then paying to bend it back into your old process. Fowler flags this too. You end up with the product's limits and a custom system's upkeep.
When building your own pays off
Building pays off when two things are true at once. The job is specific to how your company works or wins, and it happens often enough that a workaround costs you every day. In practice, that looks like one or more of these:
- The software's main job is what sets you apart. If a product could do it, your competitors could buy the same advantage.
- Every product you trial forces the same workaround many times a day, and changing your process to fit would cost you something customers notice.
- The work runs across several systems, and no product joins them up the way your work flows.
- You need a record no product keeps in the shape you need: who did what, when and why.
- Most of your users need one small screen, and a product would charge each of them for all of it.
The record case comes up often in internal software. Say your stock moves between a warehouse, a van and a shop, and people type in counts. When stock and cash stop adding up, nothing tells you where the gap opened.
Build it the other way round and nobody types a count. Each person records what happened to each item, and the counts are the sum of those records. A missing item then points to a person, a place and a day. Few products keep a record in that shape, because it depends on how your stock actually moves.
One condition comes before all of these: know your process. Software built around a process nobody has written down turns the confusion into code. We map the current process before we build anything, for the same reason we tell firms what not to automate with AI. If the warehouse and the office each do a job their own way, a new system will pick one and break the other.
Guidoo: when the comparison is the product
Guidoo is the clearest case in our own work where the core had to be built. Albanian holiday packages are sold agency by agency, so comparing them means calling around. Guidoo puts packages from licensed agencies across the country into one search. Each package is priced as one figure covering flights, hotel, transfers and meals, and customers pay online, with instalments, in a market used to paying in person.
Travel search usually compares flights and rooms. Guidoo compares whole packages, and they come from different agencies. As the case study says, the hard part was not the booking flow. It was making packages from different agencies genuinely comparable.
That comparison is the product. If Guidoo could have bought it, any competitor could have bought it too, which is the first condition on the list above.
The hidden work on both sides
Both paths have a price on the page and work that isn't on it. The subscription page or the quote shows the first. The second arrives after you sign, and it usually decides whether the choice was right.
| Hidden work | When you buy | When you build |
|---|---|---|
| Integration | Connecting the product to your other tools, limited to what its API allows | Connecting every system yourself, and fixing each link when the other side changes |
| Workarounds | Spreadsheets and re-typing wherever the product doesn't fit | Fewer if the process was mapped first, more if it wasn't |
| Growth | Each new user may need a seat, and the feature you need may sit on a higher plan | A new user costs little; a new feature is new work |
| Lock-in | Your data and process live in the vendor's product, on its roadmap | The system depends on whoever understands the code |
| Maintenance | The vendor patches and upgrades, on its schedule | Security fixes, library updates and hosting are yours to arrange |
| Ownership | You rent the software; your data should be yours to export | You own the code only if the contract transfers it |
An API (application programming interface) is a documented way for one piece of software to read and write another's data. It comes up on both sides of the table, because it decides how much of the middle path is open to you.
What buying costs you later
A product only sees its own data. Getting it to talk to your accounting package, your email or your stock system goes through its API, and you get only what the API exposes. Read the API documentation before you sign, or ask someone who can.
Where the product doesn't fit, your team fills the gap by hand: an export to a spreadsheet, a second customer list, a column only one person understands. A growing pile of those spreadsheets is the clearest sign a product has stopped fitting, and our guide to the signs you've outgrown your spreadsheets lists the others.
Per-seat pricing grows with you. That's fair while every user needs the whole product. It stops being fair when forty people on the warehouse floor need one screen each, or when the one feature you need sits on the next plan up.
Lock-in is the slowest cost. Your data, your process and your team's habits end up inside someone else's product, on someone else's timetable.
Atlassian ended support for the Server editions of Jira and Confluence in February 2024. In September 2025 it announced that its Data Center products turn read-only on 28 March 2029. Most customers who run their own copy must now move to Atlassian's cloud or leave.
If your company is in the EU, the law helps. Since 12 September 2025 the Data Act has required software-as-a-service providers to let you export your data in a commonly used, machine-readable format. Your contract must let you switch on no more than two months' notice, with a transition of up to 30 days, and switching charges end on 12 January 2027. UK companies don't get these rights from the Data Act, so check the export terms before you sign.
Over the years, the cost of buying moves with the number of seats, and with how many go to people who barely use the product. It moves with the plan that holds the feature you need, and with paid add-ons, connectors and a partner to set it up. Read the renewal terms, and count what leaving would take in export work and retraining.
What building costs you later
Custom software is never finished. The libraries it's built from get security fixes, the browsers and phones it runs on change, and the services it connects to change their APIs. Someone has to keep up.
When the Log4j flaw surfaced in December 2021, the UK's National Cyber Security Centre gave organisations different instructions depending on who wrote the software. For applications developed in house: update the library yourself. For products from a third party: install the vendor's updates. With custom software, you're the vendor.
The second cost is the one person who understands the code. If that's a freelancer or a supplier and they move on, you're left with software nobody can safely change. A code repository in your company's name, handover documentation your team can act on, and a second developer who has read the code keep a built system alive.
Owning the code isn't automatic. Under UK law, the author of a work is its first owner, unless the author is your employee working in the course of their job. An agency or a freelancer isn't your employee, so the code stays theirs until they assign the copyright in a signed document. Other countries have their own rules, so put the transfer in the contract wherever you are.
When we build, the code, the repository, the hosting account and the documentation sit in your own accounts and are transferred at handover. That's the standard to ask of anyone who builds for you.
These are what move the size of a build:
- How many kinds of user there are, and what each may see and do.
- How many systems it connects to, and whether they have a usable API.
- How much data has to move out of old spreadsheets.
- How many exceptions the process has.
- Whether it must work offline or on phones.
- The audit trail and the reports.
- Who looks after it once it's live.
A quote that doesn't account for each of these is a guess.
A build vs buy test you can run in an afternoon
Answer the questions in order, for one job at a time. Stop at the first answer that tells you what to do.
| # | Question | If yes | If no |
|---|---|---|---|
| 1 | Do your competitors do this job the same way you do? | Buy | Go on |
| 2 | Have you trialled two products with your own data? | Go on | Trial first; you can't decide yet |
| 3 | Would changing your process to fit the better product cost you something customers notice? | Go on | Buy, and change the process |
| 4 | Is the gap at the edge, such as an import, a report or a link between two tools? | Middle path: buy, then build the gap | Go on |
| 5 | Does the workaround happen daily rather than monthly? | Go on | Live with the workaround |
| 6 | Will someone named own the system after launch: its fixes, updates and questions? | Build | Don't build yet |
Expect most jobs to stop at question 1 or 3. That's the test working. Most of what a company runs is common work, and common work should be bought.
A job that reaches question 6 with a yes is worth building. Often it's the job your customers would name if asked what you do differently. Run the test with the person who does the work every day, not only with the person who signs the invoice. They know where the workarounds are.
The middle path: configure a product, build the missing piece
The middle path means buying a product for the common work, setting it up properly, and building one small piece for the part that's yours.
Start with configuration: the product's own settings, custom fields, permissions, automation rules and reports. Many gaps close there, and configuration usually survives the vendor's upgrades. Bending the product into your old process with custom code is a different thing, and it's the costly halfway point from earlier.
Then build at the edge. Keep the product as the system of record, the one place where the true version of the data lives, and build around it through its API. Check that API before you commit. Accounting products such as Xero publish their API documentation for anyone to read.
Typical pieces are a portal where customers check their own orders, an import that ends re-typing, or a report that joins two systems. Another is a simple screen for people who don't need the whole product.
Two of our own projects made the same call on a small scale. For Shkodra Shore, a six-bedroom villa on Lake Shkodra, the site hands guests to the owners' existing booking channel instead of adding a second system. For Pelikani Kacurrel, a seafood restaurant in Zogaj, reservations go through the booking system the restaurant already runs on. In both, we built the part no booking system does, presenting the place properly, and left the booking to the product.
Guidoo sits at the other end. There, the comparison was the core, so the core was built. Most companies are closer to Shkodra Shore than to Guidoo.
When you shouldn't build
Don't commission software in any of these cases, whoever offers to build it:
- You haven't trialled a product with your own data yet.
- Nobody will own the system after launch.
- The process isn't agreed, and you're hoping the software will settle it.
- The gap costs you minutes a month, not hours a week.
- You need it working next week, and a product exists.
You may not need a studio either. If a product fits and the setup is simple, the vendor's own onboarding or one of its partners will get you there for less. If you can't tell which side of the line you're on, ask for an honest read before you commit. The written recommendation is yours to act on with or without us.
Write one page before you ask for a quote
Before you talk to a vendor or a studio, write one page about the job. Say who does it, how often, and which tools it touches. Note where the workarounds are, and what you'd lose by changing your process to fit a product.
Take that page into two product trials. Two weeks of real work will tell you more than any comparison article, this one included. If a product survives them, buy it and stop there. If both break in the same place, that place is the piece to build, and your page is already the first draft of the brief.
Questions
Doesn't AI make custom software cheap to build now?
AI makes the first version faster to produce, and we use it for most of our own production work, with a person making every call that matters. It doesn't change the rest of the list: the security updates, the person who understands the code, the exceptions the demo skipped and the second release. Generating something that looks finished has never been easier. A system that looks done on day one still needs an owner for years.
Can we start with a product and build later?
Yes, and it's often the best order. Run the product for a few months, write down every workaround, and keep your data exportable. If you do build later, those notes are most of the specification, and the product's export becomes your data migration.
Where do low-code tools fit?
Tools such as Microsoft Power Apps, Airtable and Retool sit between the two paths: you buy a platform and build on top of it. They suit simple internal tools with a handful of users. Before you commit, check whether they charge per user, what you can export if you leave, and who will maintain what gets built. A low-code app still needs an owner.
How we wrote this: drafted with AI, then checked and edited by the people who build our projects. Figures come from our own work or from the linked sources.