This question gets argued badly because both sides have an incentive. What follows is the framework we actually apply, including the part where the honest answer is “buy the product, you do not need us”, which is the answer we give more often than you might expect.
Start by being honest about which problem you have
Nearly every build-versus-buy conversation is really one of three different problems wearing the same clothes.
- “We have no system at all.” Everything is in Excel and WhatsApp. Almost always: buy something. Any structured product beats no system, and you will learn your real requirements by using one.
- “Our product does 70% and we work around the rest.” This is the genuine decision point, and the rest of this guide is about it.
- “We want something nobody sells.” A genuinely unusual process, or software you intend to sell to others. Build — there is nothing to buy.
If you are in the first group and reading a build-versus-buy article, you are three months early. Buy the cheapest credible product, use it for a year, and come back with requirements instead of intentions.
The five questions
1. How many people will use it every day?
Per-user pricing is linear and forever; a build is a one-time cost with a maintenance tail. At three users, buy. At twenty, build is usually cheaper within two to three years. Between six and ten is where the other four questions decide it.
| Daily users | Three-year subscription at ₹2,500/user/month | Typical custom build + maintenance |
|---|---|---|
| 3 | ₹2.7L | ₹4L–6L |
| 8 | ₹7.2L | ₹5L–8L |
| 15 | ₹13.5L | ₹6L–10L |
| 30 | ₹27L | ₹8L–14L |
2. Is your process a genuine differentiator, or just a habit?
This is the question most businesses answer wrong, in the flattering direction. If your way of quoting wins you business that competitors cannot win, that is a differentiator and software should encode it. If it is simply how the previous office manager set it up in 2016, that is a habit, and bending a product is cheaper than encoding it.
A useful test: can you explain, in one sentence, why a customer prefers you because of this process? If not, it is a habit.
3. How often does the product make you leave the product?
Count it for one week. Every time someone exports to Excel, keeps a parallel sheet, or re-types something the system should already know — one tally mark. Under five a week is normal friction. Over twenty and you are paying a subscription for a system your staff are working around, which is the worst of both models.
4. What happens to the data if the vendor disappears?
Not a theoretical risk in the Indian SMB software market, where small vendors come and go. You will get a CSV of your main records. You will not get templates, configuration, workflow rules or attachments. If your business cannot survive losing those, ownership stops being an abstraction.
5. Will your model be the same in three years?
If you are about to add a B2B channel, open branches, start manufacturing what you currently trade, or add a service line, you will outgrow a configured product mid-contract. Building for a model you are about to leave is the most expensive mistake available in this decision.
The failure modes, side by side
| Buying fails when... | Building fails when... | |
|---|---|---|
| Cause | The product almost fits and you configure around the gap | Nobody on your side can decide the rules |
| Symptom | Parallel spreadsheets, re-typing, staff workarounds | Scope grows, deadline slips, cost rises |
| When you notice | Month 4–8, once novelty wears off | Week 6–10, at the second milestone |
| Cost of the mistake | The subscription plus the wasted hours | The build, if abandoned |
| Prevention | Trial with your three hardest real cases | One decision-maker, written scope, milestone payments |
Custom software rarely fails on code quality. It fails on dependency — the system works, the developer moves on, and nobody else can change it. Fix this in the contract, not afterwards: repository in your company's name, hosting in your account, and a handover that includes a local setup another developer could run. A vendor who resists all three is the risk.
The hybrid most businesses should actually run
The framing as a binary is mostly false. The arrangement that works for most Indian SMBs above about ten people is: buy the commodity, build the differentiator, connect them.
- Buy accounting. Tally or Zoho Books. Nobody wins by building their own GST filing.
- Buy payroll and compliance. The rules change and somebody else should track them.
- Build the operational core — the bookings, the admissions, the production floor, whatever your business actually is.
- Connect them, so your custom system pushes invoices into the accounting product rather than duplicating it.
This keeps the build small and focused on where it earns its money, and it is the shape of nearly every system we end up delivering.
If you build, how to not get hurt
- Pay in milestones tied to working software you can log into, not to dates or documents.
- Insist on a written scope with exclusions. What is not included is more useful than what is.
- Own the repository and the hosting from day one, in your company's name.
- Go live in modules. A system that goes live in week six and grows is enormously safer than one that arrives in month six.
- Agree the maintenance rate up front, before you are dependent and before your leverage disappears.
- Ask for the handover spec in writing — what a new developer would receive if they took over tomorrow.
The short version
Under five users, or with no system at all: buy. Over fifteen users with a process that genuinely wins you business: build. In between, count how many times a week your product forces you out of it, and let that number decide.
And in nearly all cases, buy the commodity, build the differentiator, connect the two. If you want a second opinion on which side you are on, ask us — if a product already does it, we will name the product.
Frequently asked questions
Is custom software always more expensive?
What is the biggest risk with custom software?
Can we start with a product and move to custom later?
How do we know if a product can be configured enough?
What should a custom software contract include?
Not sure which side you are on?
Describe your process in one call. If a product already does it, we will name the product and you can stop reading our website.