We build custom software, and we talk clients out of it regularly. Both of those are the job.
The build-or-buy decision usually gets framed as cost against features, which is the wrong frame. Off-the-shelf tools have become very good and very cheap, and the feature gap that used to justify a build often closes with a subscription and an afternoon of configuration.
The question that actually decides it is narrower: is the process you are automating genuinely specific to your business, or does it just feel that way?
The Default Is Buy
Start from the position that you should buy, and require a build to argue its way past that.
The reason is not that custom software is bad. It is that buying has a cost profile most people underestimate the advantage of:
- The vendor amortises development across thousands of customers
- Someone else handles security patches, uptime, and compliance
- It works this week rather than next quarter
- Integrations to other common tools already exist
- If it turns out to be wrong, you cancel
Custom software inverts every one of those. That does not make it wrong, but it does mean the burden of proof sits on the build.
Four Reasons to Build
Custom is justified when at least one of these genuinely holds. Not "sort of". Genuinely.
1. The process is your competitive advantage
If how you do something is why customers choose you, forcing it into a tool designed around somebody else's process erodes the thing you are being paid for.
A logistics company with a routing method that beats competitors on delivery time should not flatten it into a generic fleet tool. The method is the business.
The honest test: if a competitor bought the same off-the-shelf tool, would they be able to do what you do? If yes, that process is not your advantage and buying is fine.
2. Integration is the actual product
Sometimes the requirement is not a feature, it is a join. Six systems that need to behave as one, with data flowing between them and rules applied along the way.
Vendors solve for their own product's boundary. Nobody sells the middle of your specific stack. When the integration layer is where the value is, that layer is a build even if every endpoint it connects is bought.
3. Per-seat pricing has stopped making sense
SaaS pricing scales with users. At twenty users, a ₹1,200 per user per month tool costs ₹2.9 lakh a year, which is obviously cheaper than building.
At three hundred users it is ₹43 lakh a year, every year, rising with each price increase, and the maths changes completely.
The signal to watch: subscription cost growing faster than the value derived from it, and no plausible ceiling. Do the five-year comparison, not the first-year one, and include maintenance on the build side.
4. Nothing exists
Rarer than founders believe, and it does happen. Genuinely novel workflows, unusual regulatory positions, and hardware integrations all produce cases where the search genuinely comes up empty.
Search properly before concluding this. Two hours of looking, including adjacent categories and tools built for other industries that solve the same shape of problem. "We could not find anything" frequently means "we searched for one phrase".
Four Reasons Not to Build
The tool is 80 percent right and you want the other 20
The most common and most expensive mistake in this decision.
That last 20 percent is rarely worth what it costs. Building it means owning the whole 100 percent forever, including the 80 percent somebody already maintains for you.
Try in this order: adapt your process to the tool, check whether the tool's API closes the gap, look at a specialist competitor, then consider a build. Most gaps close at step one or two, and the discomfort of changing a process is usually smaller than the cost of owning software.
It is a common problem
Accounting, payroll, CRM, helpdesk, email marketing, project management, HR. Thousands of companies have the same requirement, dozens of vendors compete on it, and any of them will do it better than a first version you write.
Building a CRM is almost always a mistake. Not sometimes. Almost always.
Nobody will own it afterwards
This is the reason projects fail quietly, and the one least often discussed before signing.
Custom software is not a purchase, it is a commitment. Someone has to fix bugs, apply security updates, keep dependencies current, and adapt it when the business changes. If there is no plan for that beyond "the agency built it", you are buying a system that will slowly rot until it becomes an emergency.
Budget 15 to 20 percent of the build cost annually for maintenance. If that number is unacceptable, the build is unaffordable and it is better to know now.
The requirements are not settled
Building software for a process you are still inventing means paying to encode this month's version of it in code. Buy something flexible, run the process for six months, and build when you know what it actually is.
The Comparison Nobody Runs Honestly
Both options hide costs. Put all of them on the table.
Buying hides:
- Per-seat costs at your projected headcount, not today's
- Annual price increases
- Paid tiers for features you will need later
- Integration and configuration work
- Training
- Data export difficulty when you leave, which is often deliberate
- The cost of adapting your process to the tool
Building hides:
- Maintenance, at 15 to 20 percent of build cost per year
- Hosting, monitoring, and backups
- Security patching, indefinitely
- The opportunity cost of the time your team spends on it
- Knowledge concentrated in whoever built it
- Rebuild cost when the framework goes end of life
- Being wrong about the requirements
Compare over five years, not one. Year one flatters buying. Year five sometimes flatters building. Neither number alone is the decision.
The Middle Options
The framing is rarely binary, and the middle is often the right answer.
Buy the platform, build on top. Use an established system for the standard parts and build custom modules for the specific ones. Common with ERP and ecommerce platforms.
Compose from existing tools. Several bought tools connected with a thin integration layer. Cheaper and faster than a monolith, and each piece stays replaceable.
Buy now, build later. Buy to learn what you need, build once the requirements have stopped moving. Losing some migration effort later is cheaper than building the wrong thing now.
Build the differentiator, buy the rest. Custom where you compete, off-the-shelf where you do not. This is the right answer more often than any other on this list.
A Short Decision Path
- Is this a common business problem? Yes, buy. Stop here.
- Is the process a genuine competitive advantage? No, buy.
- Did you search properly for existing tools? Not yet, go and search.
- Is a good tool 80 percent right? Yes, adapt the process or use the API.
- Do the five-year costs, honestly, with maintenance. Buying still cheaper, buy.
- Will somebody own and maintain it? No, do not build.
- Are the requirements settled? No, buy something flexible and revisit.
Reaching the end of that with a build still standing means you have a real case.
If You Do Build
Start smaller than feels right. Ship the narrowest useful version, put it in front of real users, and let their behaviour drive what comes next. The single biggest cause of failed custom projects is building six months of features before anybody uses one of them. Our guide from MVP to product covers that sequencing, and choosing a tech stack covers the decision underneath it.
Not Sure Which Side You Are On?
Our software team works through this with clients before scoping anything, and we will tell you when the answer is a subscription rather than a project.
Describe the problem and we will give you a straight answer.