The question is not what is cheaper today. A decision matrix between an off-the-shelf tool and building, by lifespan, rate of change, uniqueness and vendor dependency.
Key takeaways
- The first month's price is not the measure; three-year cost including maintenance is.
- An off-the-shelf tool is cheaper until it almost fits - then the adaptations cost more than building.
- A process changing every quarter belongs in a flexible tool, not in code written once.
- A process that is your competitive advantage usually does not exist as a product.
- Vendor dependency is not a flaw - it is a cost to price in advance rather than ignore.
The question is almost always asked as a price question - what the tool costs versus what building costs - and that is the comparison that leads to the wrong decision in both directions. What actually decides is four other things: how long this will live, how much it changes, how unique it is to you, and what happens when the vendor changes something.
The four variables
| The variable | Leans to buying | Leans to building |
|---|---|---|
| Lifespan | Under a year | Three years or more |
| Rate of change | Changes frequently | Stable |
| Uniqueness | Standard process | Specific to the business |
| Dependency | Not critical | Operationally critical |
The decisive combination is the first two together. A stable process that will live for years justifies building even when it is not complicated; a process changing every quarter will consume in rework everything building saved in licence fees, and a flexible tool beats it even at a higher price.
When an off-the-shelf tool is the clear answer
When the process is entirely standard - document signing, appointment scheduling, recurring invoicing - and a tool does exactly that. Building there is nearly always a mistake: the tool has already solved the exceptions, the alerting and the compatibility, and that is a large share of the work.
The sign you have entered problematic territory is the sentence "it almost fits". A tool needing three adaptations or an add-on to meet the requirement ends up costing more than a focused build, and additionally leaves you dependent on two systems instead of one.
When building is the clear answer
- The process is unique and part of the business's advantage.
- It touches an Israeli system with no ready integration.
- It is stable and not expected to change materially.
- Volume is high in a way that makes per-action pricing expensive.
- The data is sensitive and you want control over where it sits.
The second line is more common in Israel than elsewhere. A process touching invoicing, allocation numbers, Masav or a local ERP usually falls outside what an international tool covers, and that logic is detailed in an ERP module versus custom development.
What vendor dependency actually means
Dependency is not only "what if the company shuts down", and that is also the least likely scenario. What actually happens is more common and no less consequential: a pricing change, a feature moving to a more expensive tier, an API version being retired, or an integration the vendor stops maintaining.
In each of those the business does not stop, but it discovers that a decision made two years ago constrains it today. So three questions are worth asking before committing: what can be exported and in what format, how much notice you get on a pricing change, and whether the critical data is reachable without the tool.
Building has dependency too; it simply changes shape. Instead of a software vendor it is the person or company maintaining the code. The equivalent question there is whether the documentation lets somebody else take over - and if the answer is no, that is a stronger dependency than any licence.
What the price comparison leaves out
Building forgets: ongoing maintenance, third-party API changes, hosting, monitoring, and who handles it when it breaks. Buying forgets: per-user or per-action pricing that grows with you, features gated to a higher tier, and the cost of leaving.
The only fair comparison is over the same horizon: what each route costs across three years, including those lines. The formula that includes maintenance is in measuring automation ROI honestly.
Is there a middle path?
Yes, and it is usually the right one for a small business: an off-the-shelf tool for the skeleton, and a small build for the unique part. For instance a commercial automation tool running the flow, plus one purpose-written component to talk to the Israeli system that has no ready connector.
The advantage is that the large, boring part - retries, queues, logs, alerts - arrives ready, and the build shrinks to what is genuinely specific. The disadvantage is two dependency points instead of one, which requires it to be clear who owns each.
Three examples that show the difference
Appointment scheduling. A completely standard process, dozens of tools exist, and nothing about it is specific to your business. Building here is nearly always waste - even when it looks simple, it will demand handling time zones, cancellations and calendar sync.
Issuing an invoice after payment. Falls in the middle: the tools exist, but the connection to Israeli invoicing software and to the business's own rules is usually not ready-made. The common solution is a tool for the flow plus a small component for the connection itself.
Pricing by the business's own rules. If price depends on a combination of quantity, customer, region and service type, this is almost always a build. No off-the-shelf product knows your rules, and forcing a generic tool to do it ends in a condition table nobody understands six months later.
The three examples illustrate the rule: the closer a process sits to the decisions that make the business distinctive, the more it leans to building - and the closer it sits to plumbing, the more it leans to a tool.
How to decide in practice
- Write the process and its exceptions.
- Find a tool and mark exactly what it does not do.
- Price the gap - configuration, add-on, or the manual work that remains.
- Price building at the same scope, including annual maintenance.
- Compare over three years, not over a month.
- Check the exit from both routes - what happens if you want to leave.
Step 2 is what shortens the discussion. In most cases two hours in a real tool, on your own data, answers the question better than any theoretical comparison - and it often reveals the tool does more than the marketing page suggests, or less.
Sources
Frequently asked questions
Which is better on a small budget?
An off-the-shelf tool, almost always. Building on a small budget produces a solution with no error handling and no monitoring, which is exactly the kind that breaks silently. A limited tool that works beats a partial build.
Does building give full ownership?
Of the code, yes. Of the dependencies, no: it still relies on third-party APIs, a hosting service, and somebody who can maintain it. Real ownership also requires documentation and a person who can open the code, not just the files.
When should you replace a tool you already have?
When the gap between what it does and what you need is widening, or when pricing has grown past the value. That decision is covered in [consolidating your tool stack](/blog/consolidate-your-tool-stack), and it is nearly always more expensive than it looks.
Can you start with a tool and move to building later?
Yes, and it is often the cheapest way to learn. A period on a ready tool teaches what is actually required, and by the time you build, the scope is precise - provided the data can be exported.
Keep reading
Related service
Business Automation
I build custom automations that remove repetitive work end to end.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build and I'll tell you the fastest reliable way to ship it.