Buying a tool versus building a system
A tool is bought once and bent to fit. A system is shaped around how the business already runs. The distinction decides most of what happens afterwards.
Both routes start the same way. A business identifies a problem, a budget is approved, something is procured or commissioned, and six months later there is a thing running. The difference shows up in year two, and by then it is expensive to reverse.
What a tool is good at
A tool is a product built for a market. Its job is to be the best available answer to a problem that thousands of businesses have in roughly the same shape. Payroll is a tool problem. Email is a tool problem. Accounting is emphatically a tool problem, and anybody proposing to build you a custom general ledger should be shown the door.
The economics are excellent when the fit is real. Development cost is spread across every customer, the roadmap is funded by people who are not you, and the security posture is maintained by a team whose entire job it is. If your process is genuinely the same as everyone else's, buying is not the cheap option. It is the correct one.
Where it goes wrong
The failure mode is not the tool. It is the adaptation tax. A product built for the median customer will fit you in most places and miss in a few, and the few are where your business is actually differentiated, because a process everyone runs identically is not a place where anyone competes.
So the gaps get filled by people. Somebody exports to a spreadsheet on Thursdays. Somebody re-keys the same record into a second system. Somebody maintains a private lookup table because the field the product offers does not mean what your business means by that word. None of these appear on the invoice. All of them are permanent.
The cost of a tool is the licence plus the work of being slightly wrong forever.
This is also why tool adoption figures and tool value figures diverge so sharply in the published research. Getting a tool in front of people is easy and is measured constantly. Getting a process rebuilt around it is neither.
Access has gone up sharply. Deep change has not gone up at anything like the same rate. Access is what buying a tool gets you.
What a system is
A system is not a bigger tool. It is a set of small, defined jobs, each doing one thing on your data under your rules, connected to the software you already run, and presented through an interface built for the people who have to use it. It is assembled rather than authored, which is why the second one costs less than the first: the parts are already ours, and only the rules around them are new.
The economics are the inverse of a tool. Higher up front, no adaptation tax, and it compounds, because every month it runs it accumulates decisions and outcomes specific to your business that a product built for the median customer has no way to hold.
How to tell which one you are looking at
- Is this process a source of advantage, or is it overhead? Overhead should be bought. Advantage should not be handed to a vendor's roadmap.
- How many exceptions does it have? A process with a long tail of special cases is a process a product will fit badly, because the tail is what makes it yours.
- How many systems does it cross? Anything spanning three or more is usually held together by a person, and that person is the system you are about to replace.
- What happens when it is wrong? High-consequence work needs a decision trail. Most products keep an audit log of clicks, not of reasoning.
Most businesses need both, and the useful version of this argument is not tools against systems. It is knowing which processes are commodity and which are the business, and refusing to buy a product for the second category or commission a build for the first. Getting that split right is worth more than either decision made well in isolation.