Ivara Labs
The question arrives at the wrong altitude. "Should we build or buy?" is asked about the business, when the only version of it that can be answered is asked about a single capability.
No operation is entirely one or the other. Every functioning company buys the overwhelming majority of its software and builds a thin layer that is genuinely its own. The work is deciding which layer that is — and it is almost always thinner than people expect, and in a different place than they assumed.
Two questions, four answers
For any given capability, two properties decide it. Is this differentiated, meaning does how you do it affect why clients choose you? And is it stable, meaning will it look roughly like this in a year?
↑ Differentiated
Stable →
One quadrant out of four says build. That ratio is roughly right for most operations.
The differentiation test
Differentiation is the harder of the two to judge honestly, because almost everything feels special from the inside. One question cuts through it:
If you did this exactly the way your closest competitor does, would a client notice?
If no, it is commodity, however much internal attachment there is to the current way. If yes, name what they would notice. A specific answer — faster turnaround, a compliance guarantee, visibility competitors do not offer — is a real candidate. A vague one is a preference, and preferences are not worth a build.
Stability is easier. If the process has changed materially twice in the past year, it is unstable, and building it now means building it twice. This is the same gate that decides whether a workflow is worth automating at all, covered in what to automate first.
The answer is usually neither
Here is the part that gets skipped, and it is the most common right answer.
Most operations in real pain do not need to build a system or buy a different one. The tools are broadly fine. The pain is in the gaps between them — the places where a person copies from one system into another, chases a status that exists but is not visible, or rebuilds a report from three exports.
That connective tissue is cheap compared to replacing anything, it does not require abandoning software your team already knows, and it removes most of the hours. It is also, by a wide margin, the least glamorous option, which is why vendors on both sides tend not to raise it.
Take it seriously before either of the other two. Replacing a working CRM is a large project with a migration, a retraining cost, and a year of people saying they preferred the old one. Making the CRM talk to the billing system is a much smaller project that removes the same manual work.
The honest heuristic: if you cannot name the specific feature the current tool lacks, you do not have a tooling problem. You have a seam problem.
What each side underestimates
Buying costs more than the licence
- Integration. Tools that do not talk are not separate problems, they are the gaps between them, paid for in connectors or in a person.
- Per-seat growth. The bill scales with headcount rather than value — the arithmetic is in what per-seat pricing actually costs.
- Process distortion. Bought software makes you work its way. Sometimes that encodes good practice. Sometimes you are contorting a differentiated process to fit a generic tool, and paying for the privilege.
- Renewal leverage. It only moves one direction, and not yours.
Building costs more than the build
- Maintenance. Hosting, monitoring, dependency updates, and someone whose job includes caring. Never zero.
- Attention. Your team's time spent specifying, testing and adopting is real cost that never appears on an invoice.
- Scope drift. "While we're in there" is how a focused build becomes an internal software department.
- Key-person risk. Undocumented, a build you own is a build only its author can run — see who owns your custom software.
Sequencing, if you decide to build
The order matters more than the decision.
Map before you scope. Most build regret traces to building the process someone described rather than the process that runs. Those differ, and the difference is where the workarounds live.
Start where the money is, not where the enthusiasm is. The first module should be the one with the largest measured cost, so the second one is funded by evidence rather than argued for again.
Ship modules, not a platform. Intake, then delivery, then billing, then reporting — each landing on its own and staying connected. A big-bang cutover concentrates every risk on a single date.
Keep the bought things you are not replacing. A build that connects to your existing accounting and calendar is a smaller build and a faster one. Replacing tools should be a decision, not a side effect.
How we answer this
We map the operation before proposing anything, and we tell people plainly when a build is not worth it. Sometimes the honest answer is a smaller build, or no build — we would rather say that than sell a platform.
Most of what we build connects the tools you already run and removes the manual work between them. Replacing something is never the starting assumption, and when a tool is genuinely costing you, we will say so.
If you want the read before the quote, that is where our approach starts — one conversation, one written map, which you keep either way. What follows from it is what we build.
Frequently asked questions
- When should a company build custom software instead of buying?
- When the capability is both differentiated — how you do it affects why clients choose you — and stable enough that it will look similar in a year. If either is missing, buy. That combination applies to roughly one quadrant of any operation's capabilities.
- How do I know if a process is actually differentiated?
- Ask whether a client would notice if you did it exactly the way your closest competitor does. If the answer is yes, name specifically what they would notice. A vague answer means it is a preference, not a differentiator.
- Is there an option between building and buying?
- Yes, and it is usually the right one. Building the connective tissue between tools you already run removes most of the manual work at a fraction of the cost of replacing anything. If you cannot name the feature your current tool lacks, you have a seam problem rather than a tooling problem.
- What do companies underestimate about buying software?
- Integration work, per-seat costs scaling with headcount, process distortion from bending your operation to fit a generic tool, and steadily weakening renewal leverage.
- What do companies underestimate about building?
- Ongoing maintenance, their own team's time spent specifying and adopting, scope drift, and key-person risk if the build ships without documentation.