EdTech Hub
A connected suite for education: learning, four editions of institutional ERP, admissions CRM, workforce HRMS, and a permanent employee record system. They share one student identity, one staff identity, and one set of numbers — which is the entire point, because the cost most institutions actually carry is not licence fees. It is reconciliation.
§ 01
Each product stands alone and is priced alone. What they share is the record underneath — which is where the value is, and why the order below is the order institutions usually adopt them in.
The teaching floor, instrumented.
One student record. Every department reading it.
Built around the class teacher and the parent.
Semesters, credits, and a university you report to.
Batch economics, instalment risk, and rank.
You set the paper. You award the degree.
The admission season, run as a system.
Faculty workload is not a shift roster.
The service record, and the proof behind it.
§ 02
Six commitments that shape every product above. They are here rather than buried in a proposal because they are the ones worth arguing with before you talk to us.
A student is created once, at enquiry, and carries the same identifier to their transfer certificate or their degree. Every module reads and writes that record rather than keeping its own copy. This is unglamorous and it is the whole argument: almost every operational cost an institution carries in software is the cost of two systems disagreeing about the same person.
Nothing here requires the whole suite. Institutions typically start with fees and attendance because those pay for themselves fastest, add the LMS or the CRM when the seasonal pain arrives, and never touch the modules that do not apply to them. A module that is off does not appear for any role — it is not a greyed-out menu item advertising an upsell.
Board formats, university submission files, service rules, retention schedules, and grading policies are configuration rather than code. That matters because these change — a university revises its IA format, a state amends its leave rules — and a change that requires a release is a change that arrives too late.
An academic institution has periods where change is impossible: the admission window, the examination cycle, the results week. Every rollout in this suite is sequenced around them, module by module, with the old system readable until the new one has run a full cycle. Single-cutover ERP projects in mid-term are the classic way these fail.
Content exports as SCORM and Common Cartridge, rosters and grades over OneRoster and CSV, records and audit logs in open formats with checksums intact. This is stated plainly because it is the question institutions increasingly must answer in their own procurement, and because a platform that cannot be left is a liability that has not been priced.
There are no customer counts, uptime percentages, or efficiency claims anywhere in this section, because we do not publish figures we cannot show you the measurement for. What we will do instead is demonstrate the platform on your own data — a past examination cycle, a month of payroll, last season's admission funnel — and let the result be the claim.
§ 03
Not a marketing abstraction. These are the specific records every product in the suite reads from and writes to, and the reason the numbers agree.
One record from first enquiry to alumnus, created by the CRM and carried by every other product without re-entry.
One person, one identity, across campuses and across products — with postings rather than duplicate employee codes.
Programmes, courses, batches, sections, and the calendar — defined once and read by teaching, examination, and workforce planning alike.
One ledger for fees, concessions, refunds, and service charges — so a no-dues certificate is generated rather than collected from four desks.
One permission model across the suite. A scope is a campus, department, batch, or record class, and every product respects it.
One outbound channel and one consent record, so a guardian who withdraws consent has withdrawn it everywhere rather than in one product.
§ 04
An honest comparison, including where buying separate tools is genuinely the better decision — which it sometimes is.
| Aspect | Separate best-of-breed tools | A connected suite |
|---|---|---|
| Feature depth | Usually deeper in any single category | Sufficient in each, and consistent across all |
| The student record | One per system, synchronised at best | One, authoritative, referenced everywhere |
| Cross-cutting questions | An export from each, matched by hand | A query |
| Integration cost | Yours, forever, and it grows with each tool | None between suite products |
| Consent withdrawal | Executed per system, and usually incompletely | Executed once, honoured suite-wide |
| Switching one component | Straightforward — that is the real advantage | Harder, which is why export is unconditional |
| Best when | You have strong IT capacity and one dominant need | Your cost is reconciliation, not features |
§ 05
An observed pattern rather than a prescription. The correct order depends on which pinch point is costing you most this year — and if you already know which one that is, start there instead.
Talk to an engineer
Tell us where your academic year actually hurts — the admission window, the fee cycle, the result week, the annual return — and we will show you that part working. A senior engineer replies within one business day.
§ FAQ
No. Most institutions run two or three products, and several run one. The registry is shared, so adding a product later does not mean migrating again — that is the actual benefit of the suite, rather than a bundled price. We would rather configure one product properly than sell you five that nobody has time to adopt.
Best-of-breed usually wins on depth within a single category, and if you have strong internal IT and one dominant need, it can be the right call — we have said so to institutions before. It loses on the questions that cross categories, which in education is most of the important ones: exam eligibility spans attendance and fees, batch profitability spans admissions and payroll, an AQAR submission spans everything. Those become a query here and a reconciliation project there.
Yes, and it is a common arrangement. The LMS reads its roster over OneRoster or a direct integration and posts marks back over an API; the CRM exports enrolled records to your ERP in a format it accepts. You lose the zero-re-entry handover and the single audit trail, which are real losses — but they are smaller than the loss of replacing a working ERP for no operational reason.
There is no price list here because a number without a scope is not information. It depends on which products, how many students or staff, how much migration and digitisation the existing records need, and whether it runs in your cloud tenancy or ours. The scoping call produces a written figure, and the migration estimate is based on a sample of your actual data rather than a headcount — because migration is where these projects most often exceed their estimate.
You do, outright, including in a deployment hosted by us. Export is available on demand in open formats — content as SCORM or Common Cartridge, rosters and grades over OneRoster and CSV, records and audit logs with checksums intact. This is unconditional and is not tied to being a current customer.
The statutory layer is: UDISE+, AISHE, NAAC, NIRF, board and affiliating-university formats, EPF, ESI, TDS, ABC, and DigiLocker are implemented against Indian requirements. The operational core — teaching, assessment, admissions, workforce, records — is not India-specific, and the suite runs for institutions outside India with that layer configured differently. We would be straightforward about which parts would need work for a given country rather than claiming universality.
Yes, and preferably on your own data rather than ours. A past examination cycle, one month of payroll, last season's admission funnel, or one retired employee's file — each of those shows more in twenty minutes than a feature demonstration shows in an hour, and each of them tends to surface something useful about your current records regardless of what you decide.
Primary sources
If you'd rather build
Before you decide