Build an internal tool or buy one off the shelf
Weigh a custom internal tool against an off-the-shelf product on maintenance exposure, integration surface and who still owns it in two years.
The product nearly fits and the quote to build is tempting
You have evaluated three products. Each does most of what you need and each gets one important thing wrong. Meanwhile a developer has looked at the problem and said it is a fortnight of work. The build quote is lower than two years of subscription and the decision appears obvious.
It appears obvious because the build quote prices construction and the subscription prices ownership. Those are not the same purchase. Comparing them directly is the single most common way small businesses acquire software they cannot maintain.
What each option costs and what each quote leaves out
A build quote excludes the next five years. It does not include hosting or the database or backups or the security patch somebody must apply or the change needed when a payment gateway alters its API or the rewrite when the process changes. It also excludes documentation which is always dropped under deadline and is the thing that makes the tool survivable.
A subscription excludes integration and exit. Getting your data in and connecting it to what you already run is work you pay for separately. Per-seat pricing means the cost rises with headcount regardless of value. And migrating out later is a project nobody budgets at the point of purchase. GST at 18% applies on both the development fee and the subscription as services.
The cost nobody writes down is attention. A custom tool sits on your roadmap forever and every request for a small change competes with work that earns revenue. That queue is the real price of building.
Who should not build
Do not build if nobody on your payroll can read the code. A tool maintained by one external developer is a dependency on one person's availability and goodwill and rates. When that person becomes unreachable you are not choosing between build and buy any more. You are choosing between a rebuild and a migration under pressure and both happen at the worst moment.
Do not build while the process is still changing. If how you do this work has changed twice in six months then any tool you build encodes a version of the process that will be wrong by delivery. Configure a flexible product and let the process settle first. Businesses commission bespoke workflow software precisely when they understand the workflow least.
Building is defensible when the tool is the thing that makes you different from competitors. A pricing engine or a routing model or an assessment method that is your actual advantage should not be rented from a vendor who also rents it to them. Building is also defensible for a problem no product addresses at all. Neither of those describes a leave tracker.
How to decide
Start by separating must from prefer in writing before you look at anything. Then take the best product and attempt to live with the gap for one month using a manual workaround. Most important-sounding gaps turn out to be a spreadsheet and a weekly ten minutes. The remainder are genuine and now you know which.
Then count the integration surface. A tool that must exchange data with three other systems is three ongoing relationships regardless of whether you built it or bought it. A bought product usually arrives with connectors maintained by somebody else. Every connector in a custom build is yours to repair when the other side changes.
Finally price the cost of being wrong. If a bought product disappoints you move in a quarter and lose the setup fee. If a build disappoints you own an asset nobody wants and the sunk cost will argue for persisting with it for another year. Where those two risks are close in value the cheaper mistake wins.
How to judge it a year later
Feature count is the flattering measure and it is the one a build gets praised for. A custom tool that does fourteen things your team uses three of is a maintenance liability dressed as an achievement.
Judge it on two numbers. Hours per month spent maintaining and supporting the tool including the questions your team asks about it. And the share of the intended users who actually use it weekly. A tool with maintenance hours rising while weekly users stay flat has stopped being an asset and the earlier you call that the cheaper the exit.
The common mistake
The expensive error is building to escape a subscription. The arithmetic looks sound and it omits that the subscription included a support team and a security programme and continuous improvement you now provide yourself. Businesses save a modest annual fee and acquire an obligation that outlasts the person who argued for it. The replacement cost arrives two or three years later as an urgent unbudgeted rebuild.
The second error is building without an owner named in advance. Not the developer. Somebody internal who is accountable for the tool working and who will still be there next year. A custom tool with no internal owner degrades quietly until the first failure and then nobody knows how it was deployed or where the backups are or whether there are any.
This guide explains how something works. It is not legal, tax or financial advice, and rules change. Confirm anything regulatory with a qualified professional before you act on it.