Decide on five-year cost and control, not the first invoice
If you are a manager choosing between commissioning your own software and buying an existing ERP or subscription product, the first quote rarely tells you which is cheaper or safer. What matters is the total cost over the years you will use the system, how easily you can leave if the arrangement stops working, who owns your data and code, and who updates the software when Indian rules change. This article gives you a framework to answer those four questions and present the result to your directors or trustees.
It assumes you already understand the basic difference between the two types. If not, start with our beginner's guide to custom and ready-made software and come back here.
Build a cost sheet that covers three to five years
Total cost of ownership means every rupee and every staff hour the system will consume from the day you sign to the day you replace it. For most business software, three to five years is a reasonable horizon: long enough for recurring costs to show, short enough that estimates stay realistic. Set up a sheet with one row per cost line and a column for each year, then fill it separately for the build option and the buy option using the quotes you receive.
| Cost line | Buy (ready product or subscription) | Build (custom software) |
|---|---|---|
| Upfront charge | Licence fee or first-year subscription, plus setup | Development charge, usually split into milestones |
| Customisation | Paid changes to make the product fit | Included in the build if it was in scope; extra if not |
| Recurring fee | Annual subscription or licence renewal | Usually none for the code itself |
| Maintenance and support | AMC or support plan, sometimes bundled with the subscription | AMC with the developer, or an in-house person |
| Hosting | Often included in a cloud subscription; confirm it | Server or cloud account, paid by you or through the developer |
| Changes after launch | Feature requests, if the vendor accepts them | Change requests priced by the developer |
| Third-party usage charges | SMS, WhatsApp and payment gateway fees | The same charges apply |
| Staff time | Training, data entry and a period of parallel running | Requirement meetings and testing, plus training and data entry |
| Exit cost | Data export and migration to the next system | Handover to a new developer, or migration |
Fill the sheet with figures from written quotes, not memory. Where a vendor cannot give a figure, such as for future change requests, write down your own assumption and label it, so the board can see which numbers are firm and which are estimates.
Put a number on staff time
Staff time is the line most comparisons leave blank, and it often decides the outcome. A custom build needs a person from your side who explains the process, reviews screen designs, answers questions within a day or two and tests each module. A bought product needs less of that, but still needs someone to prepare masters, clean old data and attend training.
A simple way to estimate it: list the people involved, estimate the hours each will spend per week during the project and for how many weeks, and multiply by a fair hourly cost based on their salary. Add the first weeks after launch, when staff work more slowly and often keep old registers alongside the new system. The result is not precise, but it stops the board treating internal time as free.
Lock-in and exit: plan how you would leave
Lock-in means it has become too hard or too expensive to move away from a system, even when you are unhappy with it. It happens with both options, in different ways.
When you buy
Your records live in the vendor's product. If you stop paying a subscription, access may end. Before signing, ask how you export all your data, in what format (spreadsheet, CSV or database backup), whether export includes history and attachments, and how long data is kept after the contract ends. A product that can only export a summary report is a lock-in risk.
When you build
You depend on the developer who knows the code. If that company closes or the relationship breaks down, someone else must take over. That is only realistic if you hold the source code, the database, documentation of how it is set up, and the passwords to the server, domain and any third-party accounts. Without these, a custom system can be harder to leave than a bought one.
Write the exit into the contract on day one: what is handed over, in what format, and within how many days of a request. It costs nothing to agree while relations are good.
Data ownership and source code: settle them in writing
Your customer, patient, student or employee records belong to your organisation, whichever option you choose. The contract should say so plainly, and should say that the vendor or developer may use the data only to provide the service. For a bought product, also check where the data is stored and who at the vendor can see it.
Code ownership is a separate matter. With a bought product, the maker keeps ownership and you receive a right to use it. With a custom build, ownership depends entirely on the agreement: some contracts transfer the code to you, some give you a licence to use it, and some keep it with the developer. None of these is wrong in itself, but you should know which one you are signing. Our checklist of what to check before hiring a software development company covers the contract wording to look for.
When rules change: who updates GST, payroll and other compliance logic
Indian businesses work under rules that change from time to time: GST rates, return formats and e-invoicing requirements, provident fund and ESI contributions, professional tax that differs by state, and sector-specific rules for schools, hospitals and pharmacies. Software that calculates tax or statutory deductions has to change when the rules do.
With a bought product, the vendor usually updates the software for all its customers, because every customer faces the same change. Ask whether these updates are included in your AMC or subscription, and how quickly past changes were released. With custom software, each change is work for your developer, and you pay for it unless your maintenance agreement covers statutory updates. Either way, your accountant or CA should confirm current rates and rules from official sources such as the GST portal and EPFO, rather than relying on the software alone.
A scoring method for the management meeting
Once the cost sheet is filled, score both options against the factors that matter to your organisation. Agree the weights before anyone looks at the scores, so the discussion is not steered towards a favourite.
- List the criteria: fit to your process, five-year cost, time to go live, control over future changes, exit risk, compliance updates and the staff effort you can spare.
- Give each criterion a weight out of 10 based on your priorities. A hospital may weight compliance and data protection heavily; a fast-growing distributor may weight control over changes.
- Score each option from 1 to 5 on each criterion, using the quotes, demos and contract drafts as evidence.
- Multiply each score by its weight and add up the totals for each option.
- Treat a close result as a reason to run a short pilot before deciding, not as a tie to break by instinct.
| Criterion | Weight (1-10) | Buy score (1-5) | Build score (1-5) |
|---|---|---|---|
| Fit to process | |||
| Five-year cost | |||
| Time to go live | |||
| Control over changes | |||
| Exit risk | |||
| Compliance updates | |||
| Staff effort |
Where MATROP sits on both sides of the decision
MATROP PRIVATE LIMITED sells ready products for common sectors, including retail and distribution, payroll, school, hospital and pharmacy software, and also builds custom ERP, CRM, portals and mobile apps. That means we can quote both options for the same requirement. If you ask, we will price a configured product and a custom build side by side so the figures drop straight into your cost sheet.
You should still compare our figures with other vendors. Do not choose to build if a mature product already fits your process and your team cannot spare time for requirement meetings and testing. Buying is also the safer choice when compliance logic, such as payroll deductions, changes often and you would rather the vendor carry that work. Building makes sense when your process is a genuine advantage, or when several parties need to work on the same records in a way no product supports. If you would like help filling the sheet, contact us with your requirement.
Questions people ask
How many years should a build vs buy comparison cover?
Three to five years suits most business software. Shorter periods hide recurring fees and maintenance; much longer ones depend on guesses about technology that nobody can make reliably.
Does custom software automatically belong to us once we pay?
No. Ownership of the source code depends on the contract. Some agreements transfer it and some grant a licence to use it, so agree the position in writing before development starts.
Will a bought ERP be updated when GST rules change?
Product vendors generally release updates for rule changes because all their customers need them, but whether these are included in your fee varies. Ask the vendor to confirm this in the AMC or subscription terms.
What is the biggest hidden cost in building software?
Usually the time your own staff spend explaining the process, reviewing designs and testing. Estimate it in hours and include it in the comparison alongside the developer's quote.
