Build vs buy: when to build your own internal app instead of paying for SaaS

Build when the need is specific to how you work and the data already lives in your systems. Buy when the need is generic and well served by a mature product. That line has not changed, but where it falls has, because the cost and time of building have dropped sharply when the build is directed through Claude rather than handed to a development team. The result is a more even calculation than the old default of buy-unless-you-are-a-software-company allowed.

So this is the judgement piece behind the pillar, the rule for deciding rather than another build story. It sits in our Business Automation collection, alongside how we automated time tracking and invoicing and why we built client onboarding to stop and wait for a human. Here is the rule, the worked example behind it, and the caution that keeps it from becoming "build everything."

The old default, and why it made sense

For decades the rational default was simple: buy unless you are a software company. It made sense because building meant developers, budgets, and maintenance you could not staff. A custom internal tool was a project with a real cost and an ongoing burden, so unless software was your actual business, the maths almost always favoured buying a subscription and accepting the parts that did not quite fit. The gap between what you needed and what you bought was the price of not having to build.

That default was correct for its time. When building is expensive and slow, you build only when buying is impossible, and you tolerate a lot of imperfect fit before you cross that line. Most businesses ended up with a stack of subscriptions, each doing roughly what was needed, some of them forcing little workarounds to bridge the gap between the tool's world and the business's. That was the sensible equilibrium when the build side was costly, and it held for a long time.

The reason to revisit it now is not that the rule was wrong. The rule, build for specific fitted needs and buy for generic ones, is still right. What has changed is the cost on the build side of the equation, which moves where the line falls without changing the rule itself. When one input to a decision changes by a lot, the decision changes even if the logic does not, and that is exactly what has happened here.

What changed: the cost of building dropped

The build side has dropped sharply because the build can now be directed through Claude rather than handed to a development team. That removes the developer cost, the project timeline, and much of the wait, which were the things that made building uneconomic for most internal needs. A tool that would have needed a developer and a budget can now be directed into existence by the operator who needs it, which changes what is worth building.

So the calculation is more even than it was. A fitted internal tool that reads the data you already produce can now beat a generic subscription that forces duplicate work, in cases where the build cost would previously have killed the idea before it started. The needs that were clearly buy-only a few years ago, because building them was not worth it, are now worth a second look, because the thing that made them buy-only, the build cost, has fallen. The line between build and buy has moved toward build for fitted needs.

This is not a claim that everything should now be built. It is a claim that the threshold has shifted, so the set of needs where building wins is larger than it was. Some things that were correctly bought before are now correctly built. The rule did not change. The price of one option did, which quietly rewrites a lot of individual decisions that were settled under the old prices.

The worked example: our time tracker

We made this call on our own time tracker, and it is worth walking through because it shows the rule in action. We needed billable hours. The data those hours came from already lived in our session files, the trail our work leaves as it happens. A bought time tracker would have ignored that trail and asked us to enter the hours again, by hand, into its own system every billing cycle. That is duplicate work, and paying a subscription to create duplicate work is the opposite of a saving.

So we built rather than bought, and the decision turned on exactly the two build conditions. The need was specific to how we work, billable hours out of session data, not a generic timekeeping need a mature product serves well. And the data already lived in our systems, so a fitted tool could read it directly while a generic tool would force re-entry. Both conditions pointed to build, and the build was cheap enough, directed through Claude, to be the obvious call rather than an indulgence. The tracker now calculates the hours from the session data and shortens month-end, with no re-entry.

That is the rule made concrete. We did not build because building is satisfying. We built because the need was specific and the data was ours, the two conditions that put a need on the build side, and because the build cost had dropped far enough that acting on those conditions was sensible rather than extravagant. Run your own candidates through the same two tests and the answer usually presents itself.

The caution: building is not free

The honest caution, kept in because it matters, is that building is not free even when it is cheap. A self-built tool needs oversight and carries some fragility. It does not come with a vendor maintaining it, patching it, and keeping it running while you do other things. That maintenance is real work, and for a generic, mature need, a vendor genuinely does it better than you can, which is the whole value of buying. The dropped build cost does not erase the ongoing cost of owning what you built.

So the rule has a firm second half. Build where the fit genuinely pays, meaning the need is specific and the data is yours and the fitted tool is worth the oversight it demands. Keep buying the generic, mature things that a vendor maintains better than you could, because there the fit is already good and the maintenance burden is theirs, not yours. Building everything is as much a mistake as building nothing. The skill is knowing which side of the moved line a given need sits on, case by case.

That skill is the actual deliverable of this whole pillar. The individual builds are examples. The transferable thing is the judgement: a clear rule, build for specific fitted needs on data you already hold, buy for generic mature needs, applied with honesty about the oversight a build demands. Get that judgement right across your stack and you spend on the right things. Get it wrong in either direction and you either tolerate bad fit you no longer have to, or you take on maintenance you did not need.

What a business owner can take from it

If you have a stack of subscriptions, some indispensable and some that nearly fit, the thing to know is that the build-or-buy line has moved, and some of the near-fits are now worth building instead. Run each one through two questions: is the need specific to how you work, and does the data already live in your systems. Where both are yes, building is now often the better call, because the build cost that used to rule it out has dropped. Where the need is generic and well served, keep buying.

Applying that line well to your specific stack, and being honest about the oversight a build adds, is the work, and it is where the judgement pays off or costs you. We applied it to our time tracker and built, because the need was specific and the data was ours. The rule is old and still right. What is new is how often it now points to build.

A quick way to run the test across your stack

To make this usable rather than abstract, here is how to run the two tests across a stack you already pay for. List your subscriptions, and for each one ask the two questions in order. First, is this need specific to how we work, or is it generic? A tool for sending email or processing payments is generic, a vendor does it better than you could, and it stays a buy. A tool that has to fit an unusual internal workflow is specific, and it becomes a candidate. Most of your stack will sort itself on this first question alone.

For the candidates that pass the first test, ask the second: does the data this runs on already live in our systems, or would the tool have to be fed by hand? Where the data already exists and a bought tool would force re-entry to bridge the gap, you have a strong build candidate, because a fitted tool could read what you already have. Where the tool would need its own data anyway, the case for building is weaker, because you lose the main advantage a fitted build has. The two questions together usually narrow a long subscription list down to a short list of genuine build candidates.

Then apply the honest caution before acting. For each genuine candidate, weigh the value of the better fit against the oversight a self-built tool demands, because building is not free even when it is cheap. Some candidates will clear that bar and some will not, and the ones that do are where building now beats buying. Run this once across your stack and you will usually find a handful of tools you are paying to approximate something you could now fit exactly, and a larger number you should keep buying. That sorted list is the whole point of the rule.

The same judgement applies to the documents a business produces, which can be left to drift or built to hold a standard. Ortopylot captures a brand once so every document a business produces comes out finished and on brand from one short instruction, which is the system we build for clients like Pulse Technology Hub. If you want this kind of automation built into your business, start a conversation at ortopylot.com.