October 08, 2026
Buy off the shelf when a product already does what you do, the way you do it, and you will use most of what you pay for. Build custom when your process is the thing that makes you money and no product follows it, when you are paying for ninety features and using six, or when the real system has quietly become a spreadsheet that three people edit at once. That is the whole decision. Most small businesses should start with the first option, and move to the second for one specific job, not for everything.
The rest of this piece is how to tell which side of the line you are on, what each route costs over three years, and why the ERP question in India usually has a third answer.
Custom software is a program written for one organisation, to its own process, and owned by it. Off the shelf software is a product built for thousands of organisations, rented monthly per user, and configured rather than changed.
The custom tools we build are mostly small and specific: a dealer portal with each dealer's own prices, a dispatch tracker with vehicle and LR number, a quotation tool that prices a job in three currencies, a calculator on a website, a digital visiting card system for a sales team, a dashboard that shows an owner the day's numbers on their phone. A focused tool of this kind takes 4 to 8 weeks with us, including a clickable prototype before any code, and the same people write the brief, design the screens and build them. At handover the client owns the source code, the design files and the hosting, in their own name.
Two examples on public sites. Atal Solar's website carries a solar calculator for homeowners alongside the product pages; it is a small custom tool inside a larger build. Smart Waste is an app design with a fleet dashboard and a live tracking map, which is custom software from the first screen because no product tracks that fleet that way.
When the job is the same in your business as in ten thousand others. Accounting and GST returns (Tally, and your accountant already knows it). Email and files (Google Workspace). Payroll. A helpdesk. A CRM for a small sales team. An online store with standard products (Shopify). Video calls. None of these should be built.
The signs that a product will fit:
The advantages are real: the cost is spread monthly, updates and security are someone else's job, support exists, and it works today. The rule we give clients is simple. Never build what Tally does. Never build what Shopify does. Build the thing that sits between them and your factory floor.
It stops working slowly, and the signs are easy to live with for a year too long.
You pay per user for staff who use one screen. The subscription grows with headcount while the value does not. The person in dispatch has a full licence to type a vehicle number.
You export to Excel to do the actual work. The product holds the data, the spreadsheet holds the logic, and a person carries things between them every morning.
Two products are glued together by a person. Orders in one, stock in another, invoices in a third, and one employee whose job is retyping.
The process bends to fit the product. A Morbi tile exporter's packing list runs on boxes, square metres per box and pallets per container; a generic inventory product knows "quantity". A manufacturer's dealer has a credit limit and a price tier; a generic CRM knows "contact". So the staff keep the real rules in their heads and the product holds a simplified copy.
The vendor changes something. A plan doubles in price, a feature moves to a higher tier, or the product is discontinued, and you find out how easy the export really is.
When three of these are true, you are already paying for custom software. You are paying for it in salary, in errors and in the evenings someone spends reconciling, instead of paying for it once.
Find the spreadsheet that everyone opens every day. Not the one for the accounts; the one that actually runs the business. Orders, dispatch, follow ups, production, whatever it is.
Look at it honestly. Does it have more than five tabs? Colour coding that only one person can explain? A filename ending in "final v7"? Two people asking each other "did you update the sheet"? Formulas nobody dares touch? A copy on someone's phone that is a week old?
If so, that spreadsheet is your custom software. It already has your process in it, your columns, your rules. What it lacks is a login, validation so a date cannot be typed in the price column, a history of who changed what, a version on a phone, and a way for the order to arrive in it without being typed.
Building the tool that replaces it is the most focused kind of custom project there is, because the brief is already written. List the columns, who is allowed to edit which, what starts a row (an enquiry, an order, a truck leaving), and what reports come out of it on Friday. That list is most of the brief we would write with you, and it is why these projects fit in 4 to 8 weeks.
The test cuts both ways. If the spreadsheet has two tabs, one owner and no complaints, keep it. Not every sheet needs to become an app, and a good sheet is cheaper than a mediocre tool.
There is no single number, and anyone who gives you one before a written brief is guessing. The price follows the weeks of design and development, and the weeks follow five things: how many screens and user roles there are, how many systems it must talk to (Tally, Zoho, a payment gateway, WhatsApp), whether old data must be migrated and cleaned, what reports it must produce, and whether it needs a mobile app or works in the browser.
For orientation, the nearest market band we work from is for a simple single platform app, roughly 3,00,000 to 8,00,000 rupees. A focused web tool with a login, a handful of screens and one integration tends to land in a similar region; a mid sized product with a backend and both mobile platforms runs roughly 8,00,000 to 25,00,000; larger systems go above that and are built in stages so each stage pays for itself. What moves a project from the bottom of a band to the top is almost always integrations and roles, not screens.
Running costs are small next to the build: domain 800 to 1,500 rupees a year, hosting 3,000 to 15,000 a year for a tool on shared hosting and more when it holds large files or heavy traffic, and a maintenance plan of 1,000 to 10,000 a month depending on whether it covers only backups and updates or also small changes.
Our process is a conversation, then a short written brief we prepare, then a fixed quote with a timeline. Nothing starts until you have both, so the number you agree to is the number.
Do this sum on paper before choosing. Three years is long enough to show the shape and short enough that the software will still be in use.
Off the shelf over three years: the monthly fee times the number of users times 36, plus setup and training, plus the add-ons you will discover you need in month four, plus the staff hours spent on the workarounds every week, plus the export and migration cost when you leave. Take your current invoice and multiply; then add the users you will hire. That last line is the one people forget: the subscription scales with your success.
Custom over three years: the build, once, plus hosting for three years, plus the maintenance plan for 36 months, plus the changes you ask for as the business changes. A tool at the bottom of the band, about 3,00,000 to build, adds roughly 9,000 to 45,000 for hosting and 36,000 to 3,60,000 for a maintenance plan over three years, depending on what the plan covers. After that the line is flat. Adding a user costs nothing.
The two lines cross at different points for different businesses. A five person office on a modest subscription may never reach the crossing, and should stay off the shelf. A thirty person manufacturer paying per seat, with two people retyping between products, usually crossed it a year ago.
Count the hidden line honestly. Half a person's day spent on workarounds is a salary line that belongs in the off the shelf column, and it is the one that decides most of these sums.
An ERP promises everything in one place: accounts, stock, purchase, sales, production, HR. For a large manufacturer with several plants and hundreds of users, it can be the right tool. For a small business the usual story is different: a long implementation, licence fees per user, a consultant on a retainer, staff who keep their spreadsheets anyway, and Tally still doing the accounts because the accountant refuses to move.
About 30 people a month in India search for "erp for small business india", and most of them, in our experience, need the third answer. Keep Tally for accounts and GST returns. Keep the off the shelf products that already work. Build the one tool that covers the gap between them, and connect it to Tally so an order marked dispatched becomes a voucher without anyone typing it twice. We integrate with Tally, Zoho, HubSpot and Google Workspace regularly, and the integration is usually where the value sits.
A full ERP earns its place when the business has multiple plants or companies, statutory needs across them, and enough users that a dedicated team can own it. Below that, a focused tool with good integrations does the same job for a fraction of the effort, and the staff actually use it.
Ask any vendor, and any developer, one question: what do I have if we stop working together?
With off the shelf software, you own your data, in principle. In practice you own whatever the export produces, in whatever format the vendor allows, and nothing else. The software, the workflows you configured and the price are the vendor's.
With custom software built by us, you own everything at handover: the Figma design files, the design system, the prototype, the source code, the hosting account and every credential, all in your own name. You can hand it to any other developer. Handover includes training and documentation, and any ongoing work is agreed separately, so there is no lock in by design. Article 26, on digital visiting cards for a sales team, walks through the same own versus rent choice on one small product.
If the spreadsheet test named a file, that is a good enough starting point for a conversation. Send it, or a description of it, through the contact page and we will tell you whether it is a product, a tool, or a spreadsheet worth keeping.
No. It costs more up front and less per month, with no per user fee. Over three years a per user subscription for a growing team often costs more than a focused tool built once, especially once the staff time spent on workarounds is counted.
A focused tool with a prototype takes 4 to 8 weeks with us. Larger systems are built in stages, with the first stage in use before the second begins, so the business gets value early and the brief for later stages improves.
Yes. Orders, invoices and payments recorded in a custom tool can be pushed into Tally as vouchers, and Tally data can be read back for reports. We do the same with Zoho, HubSpot and Google Workspace.
Usually not. The common outcome is a long implementation and staff who keep their spreadsheets. Keep Tally, keep the products that work, and build the one tool that fills the gap and connects to them.
If you own the source code, the design files and the hosting in your own name, another developer can take over. Ask for exactly that at the quote stage, in writing, and check that the hosting and domain are registered to you, not to the developer.
Sign in with Google to join the conversation. We use it for your display name and nothing else, and your email address is never shown.
No comments yet. Sign in above to write the first one.