Published 15 September 2026
The arithmetic, first
Ready-made school ERP products in India are typically priced per student per year, commonly between ₹150 and ₹600 depending on the modules you take. For a school of 1,000 students that is a recurring ₹1.5 lakh to ₹6 lakh a year, and it does not stop.
A custom build is a one-time development cost, generally from around ₹6 lakh for a system covering admissions, attendance, fees and examinations, after which you pay hosting and support — realistically ₹10,000 to ₹25,000 a month for a school of that size.
Run those out over five years. At 500 students on a mid-priced plan the product is clearly cheaper. At 2,000 students the custom build usually costs less in total by year three. Between those, it turns on how much the standard product has to be worked around, and that is not a number you can look up.
When buying is the right answer
Buy if your school is conventional in the ways that matter to software: a single board, a fee structure that fits into heads and instalments, a grading scale the product already supports, and one campus.
Buy if you need it working this term. A product can be running in weeks. A custom build cannot, and a school that commits to one in June for a July start will be disappointed.
Buy if nobody at the school will own the project. A custom build needs someone from the school — usually the head of administration — available to answer questions for several months. Where that person does not exist, the build drifts, and the result fits nobody's process because nobody described one.
When building is the right answer
Build when the demo required the vendor to say "we can customise that" more than twice. Each of those is a change you will be quoted for, that will need redoing at the next platform upgrade, and that you will not control.
Build when you run multiple branches with genuinely different rules — different fee structures, different boards, different academic calendars — and the product wants them to be separate accounts that cannot report together.
Build when the data matters to you strategically. A custom system's data is yours, in a database you can query, and you can add anything you want to it. A product's data is yours in principle and behind an export button in practice.
The failure modes of each
Both routes fail, in predictable and different ways, and knowing which failure you are more able to absorb is a better basis for deciding than a feature comparison.
- Bought products fail by almost fitting. The system is in place, most of it works, and the office maintains a parallel spreadsheet for the two things it cannot express. That spreadsheet is permanent.
- Bought products fail by pricing changes. Per-student pricing at a growing school compounds, and the switching cost rises every year you stay.
- Custom builds fail by under-specification. Nobody described how fee concessions actually work, so the system handles the standard case and the office handles the rest by hand.
- Custom builds fail by abandonment. The developer stops responding, and nobody else has seen the code. This is why owning the source outright, in writing, is not a formality.
A middle path worth considering
You do not have to decide for the whole school at once. The part of a school ERP that most often does not fit a standard product is fees — concessions, instalments, transport and hostel heads, board-specific requirements. The parts that almost always do fit are attendance and examination records.
Several of the schools we have worked with are best served by keeping a product for the conventional parts and building only the piece that does not fit, with the two connected. It is less elegant than one system and it is frequently the cheapest honest answer.