What “enterprise-ready” actually means

What actually changes when you go from consumer to enterprise?

The unit of ownership. Everything else is downstream of that one decision.

In a consumer product every row belongs to a user id. That single assumption is load-bearing in a way that is easy to miss until you try to remove it: queries, permissions, billing, analytics and support tooling all quietly depend on it.

In an institutional product the organisation owns the data and the user is granted access to some of it. That inverts the relationship. A teacher does not own a student's results — the school does, and the teacher is permitted to see them because of a role that exists only inside that school.

This is why 'add a team feature' is not a path to enterprise. You are not adding a layer on top of the user; you are moving the ownership boundary underneath them.

What does the hierarchy need to look like?

Organisation, then optional nestable units, then classes — and the units are the part most teams leave out.

The temptation is to ship organisation and class, and add units later when a bigger customer asks. That later change touches every permission check in the system, because 'can this admin see this class' stops being a single comparison and becomes a tree walk.

Organisation

The billing and policy boundary. One school, college or district. Everything is scoped to it and nothing crosses it.

Org unit

Campuses and departments, nestable. Optional for a single-site school, essential for a multi-branch college or a district. Retrofitting this later is painful because it changes every access check.

Class

A durable, term-scoped roster with lead and co-teachers — not an ephemeral join code. This is the object teachers actually work in.

How should roles work?

Scoped to the organisation, carried in the token, and never global.

A user must be able to be a teacher in one institution and an administrator in another without those roles leaking into each other. That means the role cannot live on the user record. It lives on the membership — the join between a user and an organisation — and the active organisation's role travels in the token.

Six roles covered every real case we encountered: organisation owner, organisation admin, unit admin, teacher, student, and a billing-only admin. The last one surprises people, but finance staff routinely need invoices without any access to student data, and if you cannot give them that cleanly, someone will share an admin login instead.

How do you isolate tenants without rewriting every query?

An organisation id on every table, indexed, enforced in the query layer and again at the database.

• Give every new table an organisation id from the first migration. Adding it later means backfilling and auditing every existing read path.
• Retrofit inherited consumer tables with a nullable organisation id so the same instance can serve both models during a transition.
• Index every one of those columns. Tenant filters appear in effectively every query, so an unindexed column is a site-wide performance problem, not a local one.
• Enforce in two places — the query layer and row-level policies. One is a mistake away from a cross-tenant leak.
• Write an audit log entry from every mutation, including staff actions, scoped to the organisation.

Is single sign-on actually necessary?

Often less than procurement implies — and the reason is worth knowing before you build it.

SSO appears on every enterprise checklist, so the instinct is to build it early. But it is worth asking who will actually authenticate through it. In school deployments, pupils frequently have no email address at all; logins have to be minted synthetically. An identity provider integration built for a population that has no identities with that provider is expensive shelfware.

Our position: build OIDC and SCIM because procurement asks and the storage design is cheap to get right up front, keep them disabled by default, and be honest internally that they may never be switched on. Deliberately skipping SAML unless a customer pays for it is a defensible call, not a gap.

The general lesson is to separate 'needed to answer a procurement questionnaire' from 'needed to operate'. They are different budgets and they deserve different levels of polish.

What should you delete?

Whatever did not survive contact with real institutions — and delete it properly.

When the consumer product became an institutional one, two significant surfaces went: the chat-based AI tutor and the video course module. Neither was failing technically. Schools simply did not use them, and every surface you keep is a surface you maintain, test, secure and explain in a demo.

Deleting is harder than it sounds because half-deleted features are worse than either state. Tables that still exist but nothing reads, feature flags that gate nothing, code paths kept 'just in case' — these accumulate into a codebase nobody can reason about. If a table is dead, say so in writing next to it, so the next person does not spend a day working out whether it matters.

What is the honest sequencing?

Tenancy, roles and rosters first. Consoles and billing after. Identity last, if at all.

• Get the boundary right before building anything on top of it — every later change is more expensive than this one.
• Persistent rosters before clever features. Teachers need the class list to be correct far more than they need anything generated.
• Analytics that need no AI — attendance, timetable, syllabus coverage — deliver value immediately and cost almost nothing.
• Seat licensing and entitlements derived from the plan, rather than a separate licence table you now have to keep in sync.
• Identity integrations when a paying customer asks, not when a checklist does.