The instinct to build is usually wrong, and the instinct to subscribe is usually right — until it is not. The trick is knowing which situation you are in before you spend six figures finding out.
Start by trying hard to buy
Genuinely. Search for existing products, book two demos, and try to make one fit. Off-the-shelf software gives you a team of engineers you do not employ, a security program you do not run, and features shipped while you sleep. That is an enormous amount of value for a monthly fee.
Most "we need custom software" conversations end here, and that is a good outcome. Adapting your process to a solid product is almost always cheaper than encoding your current process in code forever.
The four questions that decide it
1. Is this process actually your differentiator?
If the way you do this thing is why customers choose you, custom is defensible. If it is payroll, accounting, ticketing, or CRM, it is not a differentiator no matter how strongly people feel about it. Buy those.
2. How far off is the best available product?
If a product covers 80% and the missing 20% is annoying, subscribe and adapt. If it covers 50% and the missing half is the part that makes you money, custom starts to make sense. Be ruthless here — "it does not work the way we do it" is not the same as "it does not work."
3. What does the subscription cost at scale, in three years?
Per-seat pricing looks cheap at ten users and different at two hundred. Run the arithmetic on your projected headcount, not today's. This is where the crossover usually lives.
4. Can you live with their roadmap and their exit?
With SaaS you accept someone else's priorities, their price rises, and the possibility they get acquired and sunset the product. Ask how you would get your data out. If the answer is unclear, that is a risk with a number attached.
Where the crossover actually falls
A rough sketch, for a tool 25 people use:
- SaaS: $40/user/month = $12,000/year. Over five years, ~$60,000, rising with headcount and price increases.
- Custom: $55,000 build + ~$10,000/year = ~$95,000 over five years, flat regardless of headcount.
At 25 users, subscribe. At 150 users the same comparison inverts hard, because the custom line barely moves and the SaaS line triples. Seat count is the variable that decides most of these, and it is the one people forget to project.
Three cases where building is almost always wrong
- A solved commodity. Email, accounting, payroll, helpdesk, CRM. These are mature markets with good products. Building here is a hobby.
- Nobody will own it. Custom software needs a person responsible for it. Without that, it becomes an unmaintained liability the moment the original developer moves on.
- The requirement is "like X but ours." If you cannot articulate what is genuinely different about your need, you are buying familiarity, and it costs six figures.
The option people miss
It is rarely all-or-nothing. Frequently the right answer is buy the platform, build the gap: keep the off-the-shelf system as the system of record, and build a small custom application for the specific workflow it handles badly, connected by API.
You get the vendor's security and roadmap for the commodity 80%, and a tool that fits for the 20% that matters. It is usually a fraction of the cost of a full custom build, and considerably less risky.
That integration work is a large share of what we do under application development — and if the systems in question are scattered across cloud services, the cloud and infrastructure side often has to be sorted first.
Tell us the process and the product you have been evaluating — we will tell you honestly which way it should go.