Short answer
Build only when the process is how you compete, when no product fits without changing something that costs you, when you would otherwise pay for several overlapping tools plus manual data shuffling, or when the data legally cannot leave. Otherwise buy — and across LYVIA’s own engagements with companies of ten to a hundred people the real answer is usually the third option: buy the systems of record and build the thin layer that connects them. That is a pattern from client work rather than a published benchmark. The decisive question is not cost but whether you can name the person who will own the tool in two years.
What AI actually changed
The build-versus-buy calculation genuinely moved in the last few years, and it moved less than the marketing suggests, because it moved on one term only.
Producing a working first version of an internal tool is now far cheaper and faster than it was. What did not change: specifying what the tool should do, integrating it with systems that were not designed to be integrated with, keeping it secure, supporting the people who use it, and rewriting the part that breaks when a connected product changes its interface. Those were always the majority of the lifetime cost of owning software, and they are essentially untouched.
So the honest conclusion is narrow: more things are now worth prototyping, and roughly the same number are worth operating for five years. A cheap prototype that becomes a permanent dependency is the specific trap this creates.
Three options, not two
| Buy off the shelf | Build the thin layer | Build the whole thing | |
|---|---|---|---|
| What you get | A product maintained by someone else. | Bought systems of record, plus code that connects them and enforces your specifics. | Software that matches your process exactly. |
| Cost shape | Per seat, forever, rising with headcount. | Subscriptions plus a small build and modest upkeep. | A build, then ongoing ownership that never ends. |
| Main risk | Your process bends to the product, and exit is expensive. | The layer becomes undocumented and only one person understands it. | Nobody owns it in two years and it becomes untouchable. |
| Right when | The process is ordinary for your industry. | The systems exist but the join between them is yours. | The process is how you compete, or the data cannot leave. |
The four cases where building wins
- The process is a differentiator. If how you quote, schedule or deliver is why clients choose you, a product that makes you work like everyone else erodes the reason they do. This is rarer than companies believe: in LYVIA’s experience most internal processes are ordinary, and thinking otherwise is the most common reason we see for a build that should not have happened.
- Nothing fits without a costly compromise. Not “nothing is perfect” — specifically, adapting would remove something clients value or add manual work that scales with volume.
- You would otherwise buy four tools and move data by hand. Several overlapping subscriptions plus the labor of reconciling them frequently costs more than one focused build, and it costs more every year.
- The data cannot leave. A client contract, a tender commitment or a regulator. This is the only one of the four that is not a judgement call.
Where off-the-shelf wins, and why it is most of the time
Anything that is a solved, regulated or fast-moving problem should be bought, and the reasoning is the same in each case: someone else is paying to keep it current, and you cannot match that spend.
- Accounting, payroll and anything touching tax. The rules change and someone else tracks them.
- Authentication, payments, email delivery. Solved problems where a bespoke version is a liability rather than an asset.
- Anything where the vendor’s roadmap outpaces yours. Most obviously the AI layer itself, which is being improved faster than any internal team can match.
- Anything you would build to save a subscription. If the only argument is the monthly fee, buy it — the build will cost more in attention than the fee costs in cash.
The costs each side hides
Both options are routinely presented with half their cost missing, and the halves are different.
Buying hides the adaptation cost. A product that fits most of how you work is fine until the part it does not fit is the part clients notice, and the response is a spreadsheet running alongside it — which is now a second system nobody maintains. It also hides per-seat growth as you hire, and the exit cost when your data is in a shape only that vendor uses.
Building hides everything after launch: ownership does not stop at the demo, and what that actually costs is set out in life after delivery. None of it appears in a build quote, and all of it recurs.
Compare the two on three years, not on the purchase. Subscriptions at your expected headcount against build plus a realistic annual share for maintenance and support. The comparison usually reverses somewhere in year two, in one direction or the other — and which direction is the answer.
The thin layer that is usually the answer
In LYVIA’s own engagements, most requests that arrive as “we need a custom tool” turn out to be a join problem. The CRM holds the client, the accounting system holds the invoice, the scheduling tool holds the job, and a person spends their week carrying information between them and applying rules that exist only in their head.
The right build there is narrow: keep the three products, and build the layer that moves data between them and enforces the rules. It is a fraction of the cost of replacing any of them, it leaves the security-sensitive and compliance-heavy parts with vendors who maintain them, and it puts your effort exactly where your business is actually different. That shape is what most useful automation workflows look like, and often it needs no developer at all — automating a process without developers covers the version your own team can build.
Its failure mode is worth naming: the thin layer becomes undocumented, grows, and ends up understood by one person. Write down what it does and where it runs on the day it goes live, not later.
The question that settles it
Before the cost comparison, answer this: who owns this tool in two years, and is that a real person with time in their week?
If nobody can be named, buy — regardless of what the arithmetic says, because the arithmetic assumed an owner. A custom tool without one degrades in a specific and predictable way: it works, then something breaks, then a workaround appears, then the workaround becomes the process, and eventually the tool is a liability nobody dares switch off. The organizational side of this is the same question the whole cluster keeps returning to, set out in our guide to implementing AI in your business.
Deciding in a week
Write down the process as it actually runs, including the exceptions people handle by hand. Mark which steps are genuinely unusual for your industry — honestly, and expect the list to be short. Then trial two products against those specific steps rather than against a feature comparison.
If a product handles your unusual steps and irritates you on the ordinary ones, buy it: the ordinary steps are where your process should bend. If it fails on the unusual ones, you have the beginnings of a specification for the thin layer — and if that layer turns out to be substantial, commissioning it properly is its own discipline, covered in our guide to custom software development.
Where this decision sits against the rest of a first year is in our AI strategy roadmap.
Frequently asked questions
When is a custom internal tool actually worth building?
When the process it supports is genuinely how you compete, when no product fits without changing the way you work in a way that costs you something, when you would otherwise pay for several overlapping tools plus the manual work of moving data between them, or when the data cannot leave your systems for a contractual reason. Outside those four, off-the-shelf is usually cheaper across the life of the tool rather than only at purchase — a pattern from LYVIA's own engagements, not a published benchmark.
Has AI made building cheaper?
It has made the first version dramatically cheaper and left the rest roughly where it was. Writing code was never the largest cost of owning software — specification, integration, security, support and the changes required when a connected system changes are, and none of those collapsed. The practical effect is that more things are worth prototyping and roughly the same number are worth operating for five years.
What do people underestimate about buying?
The cost of adapting the process to the product. A tool that fits most of how you work sounds fine until the part it does not fit turns out to be the part clients notice, and the workaround becomes a spreadsheet running beside the tool. The other underestimate is per-seat pricing as headcount grows, and the exit cost when data lives in a format the vendor controls.
What do people underestimate about building?
Everything after launch. A custom tool carries a permanent ownership cost that a build quote does not price — what that consists of is covered in our guide to commissioning custom software. The build is a project with an end; the ownership is not. If nobody can be named for that role, buying is the honest answer regardless of the arithmetic.
Is there a middle option?
Usually the right one: buy the systems of record, and build only the thin layer that connects them and enforces the part specific to you. That keeps the expensive, security-sensitive, compliance-heavy components with vendors who maintain them, and puts your effort where the difference actually is. In LYVIA's own engagements, most "custom internal tool" needs in a company of ten to a hundred people turn out to be this — client observation rather than a published figure.
How do we decide without a long evaluation?
Write down the process, mark the steps that are genuinely unusual for your industry, and try two products against those steps specifically rather than against a feature list. As a working rule from LYVIA's own engagements rather than a published benchmark, if a product handles the unusual steps and irritates you on the ordinary ones, buy it — the ordinary ones are where your process should bend.
If you are weighing a build against a subscription, the fastest way through is an hour on the process and the three-year comparison. Book a call.
