Custom Software vs Off-the-Shelf: How an Indian Small Business Should Decide

A typical case: a 25-person distribution business in Bhiwandi runs on a ready-made accounting package, a CRM subscription, WhatsApp groups and four Excel sheets that one person in the office understands. Orders come in on WhatsApp, get typed into Excel, then into the accounting software, and the sales team never sees stock levels until they call the godown. The owner has been told two opposite things: “just buy a better app” and “you need custom software”.

Both can be right, for different parts of the business. In this piece I lay out how I think about build versus buy for an Indian small business: what each really costs over five years, where custom genuinely pays off, the risks people underplay on both sides, and the hybrid approach most of my clients end up with.

1. Define the two options properly

Off-the-shelf software is a product built for many businesses at once: an accounting package, a cloud CRM, a helpdesk tool. You subscribe or buy a licence, configure it, and adapt your process to it. The vendor maintains it, adds features on its own roadmap, and sets the price.

**Custom software** is built for your process. A developer or team writes it to match how you take orders, price jobs or allot work. You pay for the build and then for upkeep, but the roadmap is yours. A custom CRM tuned to how your sales team actually follows up, or an ERP-style system that connects orders, stock and dispatch, are common examples.

There is a big middle ground: off-the-shelf tools that you extend with integrations, custom fields, or a small custom app that sits on top and pulls data from them. I will come back to that, because it is often the best answer.

2. Where off-the-shelf clearly wins

For most jobs, buying is the right call, and I say that as someone who builds software. If a task works the same way at your business as at thousands of others, a mature product has already solved the edge cases you have not thought of yet.

• Accounting and GST filing. Rules change and vendors update for them. Rebuilding this is rarely worth it.
• Payroll, email, calendars and documents. Commodity tools with strong security teams behind them.
• A first CRM when you have a handful of salespeople and a simple pipeline.
• Anything you need running next week. A subscription can be live in days; custom work takes weeks at minimum.

Off-the-shelf also gives you something easy to undervalue: other users. When something breaks, there are help articles, forums and other businesses who hit the same problem. Your own custom system has exactly one user base, you.

3. The hidden costs of off-the-shelf

The low starting price is real. The catch is what happens as you grow, and what your team does to work around the bits that do not fit.

Per-user pricing grows with headcount

Most business software charges per user. Take Freshworks’ published Freshsales CRM pricing as an example: Growth at $9, Pro at $39 and Enterprise at $59 per user per month, billed annually. Here is what that list pricing looks like at different team sizes.

Source: plan prices from Freshworks CRM pricing, billed annually, checked 30 October 2026; multiplication is mine. List prices on the global page; Indian pricing, discounts and GST may differ. Used as an example of per-user pricing, not a recommendation for or against this product.

None of this makes the subscription a bad deal. A good CRM at 50 users is often still cheaper than building and maintaining your own. The point is that “cheap to start” and “cheap at scale” are different questions, and you should price the second one before you commit years of data to a tool.

Workarounds cost staff time

The bigger hidden cost is usually the spreadsheet next to the software. When a tool does not match how you work, people export, re-type and reconcile. In the Bhiwandi example, every order was typed three times. That cost does not appear on any invoice, but it is paid every day in salaries and errors.

You are a tenant

The vendor decides prices, features and what happens to old plans. Most behave reasonably, but you have little say. The practical protection is to know how to get your data out in a usable format before you need to.

4. Where custom software pays off

Custom earns its cost when the software is wrapped around the thing that makes your business different, or when gluing several tools together has become a job in itself. The signs I look for:

• Your process is genuinely specific. A manufacturer with dealer-wise price lists and credit limits, a coaching institute with batch allotment and fee schedules, a service company that dispatches technicians by area and skill.
• You are paying for many seats to use a small part of a product. For example, 40 field staff who only need to log visits and photos.
• Data lives in three or four systems that do not talk. Someone in the office is effectively a human integration layer.
• The software is part of what customers see. A dealer portal, an order-tracking page or a booking flow that becomes part of your service.
• You have outgrown the best available product after genuinely trying it, not just after a frustrating first week.

One more condition matters: the process has to be stable. If you are still changing how you price or deliver every month, building software around it locks in a moving target. Run it on spreadsheets and an off-the-shelf tool until the process settles, then build.

See also: if the main problem is repetitive manual work between tools, read AI and automation for small businesses first; sometimes automation solves it without a full custom build.

5. The risks of building: projects overrun

The honest case against custom software is that projects go wrong more often than people expect. The best-known evidence comes from large projects rather than small-business ones, but the pattern is instructive.

Source: McKinsey, “Delivering large-scale IT projects on time, on budget, and on value”, research with the BT Centre for Major Programme Management at the University of Oxford. Large corporate projects, not small-business builds; an older study, so treat it as a pattern rather than a current benchmark.

The figure I pay most attention to is the last one: value. Overruns hurt, but a system that ships and does not get used is worse. In small projects, the causes I see are familiar: the scope was never written down, the people who do the work daily were not consulted, and everything was built at once instead of one useful piece at a time.

How to reduce the risk

1. Write a one-page scope: who uses it, the three to five tasks it must do, and what “done” looks like.
2. Build the smallest version that removes real manual work, and put it in front of the people who will use it daily.
3. Pay in stages tied to working software you can try, not to documents or percentages.
4. Keep the off-the-shelf tool running in parallel until the new system has handled a full month of real work.

See also: for realistic timelines and budgets, see how long it takes to build an app and app development cost in India.

6. Ownership, upkeep and data

Who owns the custom code

Paying for software does not automatically make you its owner. Under Section 17 of the Copyright Act, 1957, the author of a work is its first owner. Section 19(1) says an assignment is valid only “in writing signed by the assignor”; if the period is not stated it is deemed to be five years, and if the territory is not stated it is presumed to be India only. So the contract should assign the code to your company perpetually and worldwide, and you should hold the source code and the server or cloud accounts in your own name. I am not a lawyer; have yours review the clause on a significant build.

Custom software needs upkeep too

Custom systems run on languages and frameworks that keep moving. As one example, PHP.net lists only versions 8.2 to 8.5 as supported as of October 2026, with 8.2 losing security fixes on 31 December 2026. Every custom system has dates like this somewhere in its stack. Budget for regular updates from day one, or the system slowly becomes a liability.

Your customers’ data is your responsibility either way

India notified the Digital Personal Data Protection Rules, 2025 on 14 November 2025, with an eighteen-month phased compliance period. The government’s explainer defines a Data Processor as any entity that processes personal data on behalf of a Data Fiduciary, and places responsibility for keeping data safe on the Fiduciary, which is your business. The highest penalty, up to ₹250 crore, applies to failing to keep reasonable security safeguards.

In plain terms: if your SaaS vendor or your custom developer stores customer data for you, they are processing it on your behalf, and you remain accountable. With off-the-shelf, check where data is stored, what the vendor’s security commitments are, and how you get it back. With custom, insist on access controls, backups and a clear record of who can see what.

7. The hybrid approach most businesses end up with

In my experience, the best answer for a growing small business is rarely all-custom or all-bought. It usually looks like this:

• Off-the-shelf for accounting, GST, payroll, email and documents.
• A small custom application for the core workflow that is specific to you, such as order capture, job allotment or a dealer portal.
• Integrations that move data between them automatically, so nothing is typed twice.

For the Bhiwandi distributor, that would mean keeping the accounting package, replacing the WhatsApp-to-Excel step with a simple order app that the sales team and godown both see, and pushing confirmed orders into accounting automatically. That is a much smaller and safer build than replacing everything.

Infoways’ own rule of thumb from client projects, not survey data.

8. Where this advice breaks down

• The overrun evidence is from big projects. The McKinsey study looked at projects with initial budgets above $15 million. Small builds fail differently, mostly through vague scope rather than complexity.
• Price examples are list prices. The Freshsales figures are global list prices in US dollars. Indian pricing, annual discounts and taxes vary, so price your actual shortlist.
• Off-the-shelf keeps getting better. Low-code tools and configurable platforms now cover processes that needed custom code a few years ago. Re-check before you build.
• Custom depends on the team staying around. If the developer disappears and the code is poorly documented, you can end up worse off than with a subscription. Documentation and source-code access are not optional.
• I build custom software. Weigh my view with that in mind; it is also why I recommend buying first for most tasks.

Checklist before you decide

The Bhiwandi owner did not need to choose between “a better app” and “custom software”. They needed to buy what was standard, build the one workflow that was theirs, and stop typing every order three times.