Why the Best ERPs are Data Platforms in Disguise

For most of the 2010s, “ERP” was a punchline. A heavy, configurable, multi-year deployment that nobody loved and most operators worked around. The market is still full of those systems. They cost a fortune, they’re slow, and the data inside them is locked behind reports that generate at 3am.

Our take is simpler: the best ERPs in 2026 aren’t ERPs. They’re Data Platforms with thoughtful operational UIs on top. That reframing changes everything about how we build them.

What “ERP” actually means in 2026

Strip away the acronym and an ERP is one thing: a system of record for the operations that keep an organisation running. Whether that’s a hospital scheduling patients, a school enrolling students, or a logistics company running shipments, the core need is the same.

A single source of truth for the entities that matter (patients, students, staff, inventory).
Workflows that capture what happens to those entities over time.
Reporting and analytics that let leadership steer.
Increasingly: automated decisions that act on the data without a human in the loop.

That last point is where legacy systems collapse. They were built to record operations, not to drive them. Bolting AI implementation or Operational Automation onto a 2005-era ERP is like adding a turbocharger to a tractor.

The legacy problem

The dominant Hospital Management Systems and School ERP vendors in market today share three pathologies:

Data trapped in proprietary schemas. Every report needs a vendor consultant or a custom integration. The data is “there” but inaccessible at the speed of operational decisions.
Workflows hardcoded for a 2010 reality. Adding a telemedicine flow, a mobile parent app, or an AI triage assistant requires re-platforming, not configuration.
Pricing scaled to capture, not value. Most vendor pricing scales with seat count or claim volume, not with how much the system actually does for you.

We replace all three by building from a different starting point — data first, screens last.

Hospital Management as a data platform

When we ship a Hospital Management System, the first thing we model isn’t the UI — it’s the data.

What an EHR actually is

It’s a longitudinal event log. Visits, vitals, labs, prescriptions, imaging, billing — each event tied to a patient identity and a timestamp. Done correctly, every screen in the system, every alert to a clinician, and every automated workflow is a query over that event log.

Where the data hides

Legacy systems hide it in 20-table joins that take 15 seconds to compute. Our default: events land in ClickHouse, get modeled in dbt, and are queryable in tens of milliseconds. Suddenly the no-show predictor, the readmission-risk score, and the bed-utilisation dashboard all run off the same source of truth with sub-second latency.

Where AI fits

Once the data layer is right, AI implementation is the easy part. We’ve shipped LLM-powered intake summaries that pull from a patient’s history in real time, anomaly flags for sepsis indicators, and automated discharge-note drafts that a clinician edits in 30 seconds instead of typing for 8 minutes. None of those features are possible on a slow, monolithic EHR.

School ERP as a data platform

The story for a School ERP is almost identical with different entities.

Beyond attendance and grades

A modern School ERP isn’t a fancier gradebook. It’s a longitudinal log of every interaction a student has with the institution — attendance, grades, fees, library check-outs, counsellor visits, parent communications, transport.

Real-time signals that actually help

The interventions schools talk about — dropout prevention, fee-default forecasting, mental-health flags — all run over that log. The reason most schools never realise these is that the data is split across five vendor systems with no shared identifier. The fix isn’t “more AI”; it’s data unification first, then Operational Automation on top.

We’ve built dropout-risk dashboards for counsellors that surface intervention candidates the week before grades drop, not the month after. We’ve built fee-collection workflows that auto-personalise reminder cadence based on payment history. None of it required new ML breakthroughs — it required a Data Platform underneath the ERP.

The data-first build approach

Our blueprint for any operational ERP:

Model the entity log first. Patients, students, transactions — whatever the core entity is. Schema before screens.
Pick the substrate by latency need. Postgres for transactional writes, ClickHouse for analytical reads, both kept in sync via CDC.
Build the operator UI last. Once the data and the workflow primitives are in place, the UI is the thin layer on top — fast to build, fast to change.
Layer in Operational Automation early. Reminders, escalations, scheduled jobs — these are not “phase 2.” They’re what makes the system feel modern from week one.
Wire AI features once the substrate earns them. No AI on top of a slow data layer. Ever.

This is the opposite of how most ERP vendors approach a build. It’s also why our Hospital Management System and School ERP deployments stay sub-second under load, and why adding a new module is a two-week project instead of a six-month re-platforming.

What this means for buyers

If you’re evaluating an ERP for a hospital or a school in 2026, the question isn’t “which vendor has the most features” — it’s “which vendor’s data layer can I actually use.” A modern Data Platform with the right operator UI will outperform a heavy legacy ERP on every dimension that matters: speed, modifiability, AI-readiness, and total cost of ownership.

Tired of legacy ERP timelines and surprise bills? If you want a Hospital Management System or School ERP built like a real data platform, we’d love to scope it. Same senior engineers, same disciplined stack — built to ship, this quarter.