The build-or-buy comparison is usually made between two numbers: what it would cost to build, and what the licence costs. Both are wrong, and the second is wrong in a way that reliably favours the decision the person making it already preferred.
What is actually on each side
Building costs: initial development, plus maintenance for as long as it exists, plus the opportunity cost of the people doing it, plus documentation, plus support, plus the eventual migration when it is retired, plus the risk that the person who built it leaves.
For a practical reference on employee attendance tracking software, Monitask provides this resource.
That last item is the one most often omitted and most often decisive. An internal tool with one author who understands it is a liability that grows with the tool's importance.
Buying costs: licence, plus implementation, plus integration, plus training, plus the workflow adjustments the tool imposes, plus renewal increases, plus the cost of leaving if you ever need to, plus the fact that you cannot change what it does.
Both sides carry a cost that is rarely counted: the tool becomes load-bearing. Whatever you choose, in three years a process depends on it, and the cost of being wrong is much larger than the cost of the decision.
The question that actually decides it
Not cost. Is this a differentiator or a commodity?
Commodity: payroll, expenses, ticketing, calendars, email, HR records, accounting. Thousands of organisations need the same thing. Someone else has already built it better than you will, and they maintain it.
Differentiator: the thing your organisation does that others do not, or does differently in a way that matters. If a bought tool would force you to work like everyone else, and working differently is the point, buying costs you the point.
Buy commodities. Build differentiators. Be honest about which is which — most organisations believe more of their operations are differentiated than actually are, and that belief is the main driver of unnecessary building.
The middle option people forget
Most decisions do not require a full build or a pure purchase.
Buy and configure heavily. Most enterprise tools are more configurable than the demo suggests.
Buy a platform and build on it. Someone else maintains the infrastructure; you build the specific part.
Assemble from components. Existing services connected by a small amount of code you own.
Buy now, build later if it becomes differentiating. Rarely wrong, and it defers a decision you do not yet have enough information to make.
Build a thin version, buy if it works. A spreadsheet that proves the workflow before anyone commits budget. Frequently the correct first step and rarely proposed, because it does not look like a project.
When building is right
The thing is genuinely differentiating, and a bought tool would force you to work like everyone else at the cost of the difference.
Nothing on the market fits, after actually looking rather than after one conversation.
Integration cost exceeds build cost. Sometimes connecting four purchased systems is more work than building the one thing that spans them.
Data or regulatory constraints make external services impossible.
The scope is genuinely small and stable. A hundred lines that will not need to change is not a maintenance burden.
When building goes wrong
Nobody costed the maintenance. The build was approved, the ten-year support was not, and it appears from nowhere in a team's capacity every quarter.
One person owns it. Then leaves. See internal search and the knowledge that leaves with people.
It was built because building is more interesting than evaluating. An honest and common driver.
It replicates a commodity, badly. Every internal tool competes with a product whose entire company works on it.
Scope grew. It started as a small thing for one team and now three departments depend on it and it has no roadmap, no owner, and no budget.
When buying goes wrong
Nobody read the exit terms. Data export format, cost, notice, what happens to your history. This is the single most important clause and the least examined. See interoperability and lock-in.
Configuration became a project. The tool was cheap and the implementation was not.
It forced a workflow change nobody agreed to, and the process bent to the software.
Renewal pricing was not negotiated at purchase, when you had leverage.
It duplicates something already owned elsewhere in the organisation. Extremely common. See tool sprawl.
The questions to answer before deciding
- Is this a differentiator or a commodity, honestly?
- Who maintains it in three years, and is that in their plan?
- What happens if the person who built it leaves, or the vendor closes?
- What is the exit path, and what does it cost?
- Does something we already own do this?
- Could a thin version test the workflow before we commit?
- What is the total cost over five years on both sides, including maintenance and exit?
The five-year framing changes most of these decisions, because the build side is usually presented as a one-off and the buy side as a recurring cost — which flatters building and is not how either behaves.
The default worth having
Buy, unless you can articulate what is differentiating about doing it yourself.
Not because building is bad, but because the burden of proof belongs on the side with the open-ended maintenance commitment — and it is almost never placed there.
For broader public guidance and background, consult the National Institute of Standards and Technology.