Custom software vs off-the-shelf: a checklist for Indian SMEs

Stay with a packaged product when most of these hold:

• The product covers your process with configuration, not code changes.
• Your team has adapted to it, and the workarounds are small and stable.
• Your user count is modest and will not double soon.
• The process is commodity work that every business does the same way: accounting, payroll for a single state, email, document storage.
• The vendor's roadmap is heading where you need to go.

For accounting, Tally or Zoho Books will beat anything custom on cost and on familiarity for your CA. Rebuilding a general ledger from scratch rarely pays.

• A shadow system in Excel. The official system holds the data, but the real work happens in a spreadsheet someone downloads, edits and uploads back.
• The same data typed twice. An order is entered in the CRM, then retyped into the billing software, then again into the dispatch register.
• Reports rebuilt by hand. Month-end MIS is assembled from three exports by one person who cannot take leave in the first week of the month.
• Per-user fees for occasional users. Shop-floor supervisors and godown staff need a login for five minutes a day, but each one costs a full seat.
• Workarounds that break on upgrades. Every product update means retesting a customisation or a TDL file.
• A process the product cannot model at all. A costing rule, a job-work flow, a dealer scheme or an approval chain that sits outside the system entirely.

Answer each question yes or no.

• Do people re-enter the same data in more than one system?
• Does a spreadsheet hold information the business depends on daily?
• Do you pay for more than 25 user seats, or expect to within a year?
• Have you asked a vendor for a change and been told it is not possible on your plan?
• Is there a process that gives you an edge over competitors, which no product handles well?
• Would integrating your current tools cost almost as much as replacing them?
• Do you need control over where your data is hosted, for a client contract or for compliance?
• Is month-end reporting assembled manually from several sources?

If you answered yes to one or two, fix those specific gaps with configuration, integrations or a small tool. If you answered yes to four or more, a custom system for the core of your operations is likely to pay for itself. In between, look at the middle path below.

Custom software brings its own lock-in if you are careless. If the only person who understands the system is the freelancer who built it, you have swapped a vendor you could replace for one you cannot. Insist on the code in your own Git repository, the database and server accounts in your company's name, and written documentation, from the first week.

Keep packaged products for commodity work, build custom only where your process is different, and connect the two.

A Pune manufacturer keeps Tally for accounts and builds a shop-floor system for production orders, material issue and finished-goods entry, which posts summarised vouchers into Tally. A Surat trader keeps his billing software and adds a small order-capture tool where salespeople log WhatsApp orders, and the godown sees a dispatch list. In both cases the custom piece is small, focused and owned outright.

This works because Tally and most cloud products can exchange data. Tally reads and writes XML, and we have built Tally XML export into our textile manufacturing ERP and Tally-importable exports into Takshiva, our school ERP.

• Hosting. A cloud server, backups and a domain, billed monthly or yearly.
• Support and maintenance. Bug fixes, security patches, framework upgrades and small changes. Budget for this every year.
• An internal owner. Someone in your business who decides how the software should behave and signs off on changes.
• Change requests. Your process will change, and the software will need to follow.

Set against that: no per-user fees, a system that fits, and an asset you own. DipanshuTech's business software starts at ₹39,999; the final quote depends on scope, which we write down in detail before pricing.

Pick one process and build it end to end, rather than five processes halfway. For a construction-material supplier, that might be order to dispatch to invoice. For a school, admission to fee collection. Each should be usable in production within weeks, not months.

Our own products grew this way. RawERP was built in eight phases for construction-material businesses, covering GST invoicing, stock, projects and dispatch, each phase usable on its own. Takshiva grew to 54 modules for schools, one module at a time.

A good first scope document names the users, the screens, the reports, the integrations and the acceptance tests. If a developer cannot tell you what "done" looks like for phase one, the estimate is a guess.

Two quotes for "an inventory system" can differ by five times and both be honest, because they describe different software. Before comparing numbers, put the quotes side by side on these points:

• Scope in writing. Does the quote list screens, reports, roles and integrations, or just module names?
• Data migration. Is importing your items, parties and balances included, or billed later?
• Testing and acceptance. Who tests, against what, and what happens when something fails?
• Hosting and deployment. Is the server set up for you, and in whose name?
• Ownership. Is the code delivered to your repository as the work progresses, or only at the end?
• Support after go-live. How long is the free fix period, and what does a support plan cost after that?
• The tech stack. Is it a mainstream framework other developers know, or something only this vendor uses?

A cheaper quote that leaves out migration, hosting and support usually ends up costing more. A higher quote with a clear scope, weekly demos and code in your repository is easier to hold to account.

Is custom software always more expensive than off-the-shelf?

Up front, usually. Over five years, not necessarily, especially when per-user fees are high or workarounds are costing staff time every month.

Who should own the source code?

You should. Make it a contract clause, and check that the repository is in your organisation's account.

What if the developer we hire disappears?

That is the risk documentation, a standard tech stack and code ownership protect against. A competent developer should be able to pick up a well-built Laravel or Node.js system written by someone else.

Can custom software work alongside Tally?

Yes. Tally can import and export XML, and a custom system can exchange masters and vouchers with it so your accountant keeps working as before.

How long does a first custom build take?

A focused first phase typically takes six to ten weeks, depending on integrations and how quickly decisions are made on your side.

Can we start on off-the-shelf software and switch to custom later?

Yes, and it is often the sensible order. A year on a packaged product teaches you which features your staff actually use. Just confirm early that you can export all your data, so the switch is a migration rather than a rescue.

Run the checklist with the two or three people who feel the pain most, not only with the owner. If the answer points to custom, start with the one process that hurts most. Our custom software development service starts exactly there, and the ERP cost guide shows how the numbers compare.