It starts the same way every time. A primary school in Cork needs parent notifications sent through a specific channel. A secondary in Manchester needs timetable data shaped to match their MIS (Management Information System, the core administrative database schools use to manage students, staff and reporting). A university in Galway needs a custom reporting format their academic council signed off on three years ago and will not revisit.
Each request is reasonable on its own. Each one takes a week, maybe two. But eighteen months into saying yes, the engineering team is not building a product any more. It is maintaining a constellation of per-school exceptions that look like one codebase but behave like forty.
This piece is about where the problem actually sits, why it compounds faster than most founding teams expect, and how to structure a platform so that school-level variation is configuration rather than code.
Key takeaways
The problem is not feature requests. It is where they land in the codebase. A school asking for something specific is healthy demand signal. Building it as a one-off branch is the mistake.
Per-school forks compound quietly. Each exception adds a small maintenance cost. Twenty exceptions together create a release pipeline that cannot move without regression testing against every variant.
Multi-tenancy is an architecture decision, not an infrastructure one. Sharing a database is not the same as sharing a product. The distinction matters because the second one is where the work lives.
Configuration layers cost more to build upfront and less to maintain permanently. The maths flips within two years for any platform serving more than fifteen schools.
Ireland's market makes this harder to defer. Small total market, high variation between primary, post-primary and further education, and no MIS aggregator to normalise the integration surface the way Wonde does in the UK.
What multi-tenancy actually means in school-facing EdTech
Multi-tenancy means multiple schools share one instance of the product. Each school sees its own data, its own users, its own branding. Under the surface, they are running on the same application code and, usually, the same database cluster.
That is the infrastructure definition. It is necessary but not sufficient. The harder question is whether those schools also share the same feature set, or whether each one is running a slightly different version of the product shaped by requests made during onboarding or renewal.
A platform can be multi-tenant at the infrastructure layer and effectively single-tenant at the feature layer. That combination is the one that causes the most damage, because the team believes it has a scalable product while the release process says otherwise.
Why schools ask for different things
Schools are not being difficult. They operate in genuinely different contexts, and those contexts produce different requirements.
A primary school in Ireland using Aladdin as its MIS needs data shaped differently from a post-primary school using VSware. A MAT (Multi-Academy Trust, a group of schools in England operating under a single governance and accountability structure) needs consolidated reporting across its schools that a standalone academy does not. An ETB (Education and Training Board, one of the sixteen regional bodies in Ireland that manage further education and training centres) needs compliance reporting aligned to QQI (Quality and Qualifications Ireland, the state agency responsible for qualifications and quality assurance in Irish further and higher education) frameworks that a voluntary secondary school does not.
These are not preferences. They are structural differences in how the school operates, what it reports, and who it reports to. A product that ignores them loses the deal. A product that accommodates them one at a time loses the engineering team.
The pattern to watch for is the moment where a legitimate structural difference gets solved with a code branch instead of a configuration option. That moment is where the technical debt starts, and it rarely announces itself.
Pro tip. Keep a log of every feature request that arrives with the phrase "we just need it to" and tag whether it was solved with configuration or with custom code. Review the ratio quarterly. If more than a third of requests are landing as custom code, the configuration layer is not expressive enough and needs investment before the next sales push.
What breaks when you say yes to everything
The failure list is predictable. It is also invisible in the first year because nothing breaks dramatically. Everything degrades gradually.
Release velocity drops. Every per-school exception is a branch that has to be tested before a release ships. At ten schools with custom code paths, the QA surface doubles. At thirty, releases that used to take a day take a week.
Bug reports become forensic work. A bug that only reproduces in one school's configuration takes three times longer to diagnose than a bug in the shared codebase, because the first step is always "which version of the feature is this school running?"
Onboarding new schools slows down. The sales team sells the product. The implementation team discovers that the closest existing configuration does not quite fit, so engineering writes another variant. Each new school takes longer to onboard than the last, which is the opposite of what scaling is supposed to do.
Pricing breaks. When every school runs a slightly different product, it becomes difficult to justify a standard price. Enterprise deals start including custom development as a line item, which turns a SaaS business into a services business without anyone deciding to make that shift.
The best engineers leave. Maintaining forty variants of a feature is not interesting work. The engineers who can architect a proper configuration layer are the same ones who will leave if they spend another quarter patching per-school exceptions.
Building on a codebase that is already showing signs of per-school drift?
We offer a complimentary Discovery Sprint assessment: a mapped view of where your current architecture sits, what is configuration and what is code, and what the refactor sequence should be before the next sales cycle adds more variation.
The architecture decision: shared core versus per-tenant configuration
The choice is not between customisation and standardisation. Schools need variation. The choice is where that variation lives.
In a shared-core model, the application code is identical for every tenant. Variation is expressed through a configuration layer: feature flags, tenant-level settings, theming, and structured data mappings. When a school needs parent notifications sent via a specific channel, that is a configuration option. When a school needs timetable data shaped for their MIS, that is a data mapping in the integration layer. The code does not branch.
In a per-tenant fork model, variation lives in the codebase itself. Each school's differences are implemented as conditional logic, separate modules loaded per tenant, or in the worst cases, entirely separate deployments. The code branches every time.
The trade-off is front-loaded cost versus compounding cost. A configuration layer takes longer to design and build. It requires the product team to think abstractly about what "variation" means before knowing every specific form it will take. That investment pays back within two years for any platform serving more than about fifteen schools, because each new school after that is configuration, not engineering.
The per-tenant fork is faster for the first five schools. By school twenty, the maintenance cost exceeds what the configuration layer would have cost to build. By school fifty, it exceeds what it would have cost to build and rebuild.
How to structure configuration without building a settings page nobody understands
Configuration layers fail when they become a second product. A settings panel with two hundred toggles is not better than forty code branches. It is the same problem wearing a different hat.
The platforms that handle this well share three structural choices.
First, they separate configuration into tiers. Platform-level defaults cover the majority case. Tenant-level overrides cover the structural differences between school types. User-level preferences cover the cosmetic layer. Each tier inherits from the one above it, so a school only configures what is genuinely different about its context, not every setting the platform offers.
Second, they treat integrations as the primary configuration surface rather than features. Most school-level variation is not about what the product does. It is about what data the product exchanges with other systems and in what shape. A well-designed integration layer with per-tenant data mappings absorbs a large share of feature requests that would otherwise become code branches. The integration mapping becomes the configuration, and the feature stays standard.
Third, they version the configuration schema. When the product evolves, older configurations migrate forward through a defined path rather than breaking silently. This is the piece most teams skip, and it is the piece that causes the most pain eighteen months later when a platform update invalidates a school's setup and nobody knows why.
Pro tip. Before building any tenant-level configuration option, write the support article for it. If the support article requires more than three paragraphs to explain, the option is too complex and will generate more support tickets than it saves in engineering time.
What this looks like in practice
The MLI International Schools platform manages operations across multiple international education centres, each with different staffing, timetabling and reporting requirements. The architecture handles that variation through role-based interfaces and centre-level configuration rather than per-centre code. Directors, teachers, activity staff, welfare officers, students and guardians each see a different interface, but the application underneath is one product. That is the distinction that allows the platform to hold up to 1,500 concurrent users during peak summer programmes without the engineering surface multiplying alongside it.
EduSmart Planner, the AI curriculum platform we built for CJ Fallon, applied the same principle to a different problem. Rather than building a separate curriculum tool for each school type, the platform serves over 100 Irish schools and 2,000 teachers through one shared codebase, with curriculum content and planning logic configured per subject and year group rather than per school. The result is a platform that updates once and deploys everywhere, rather than one that requires a separate release for every school variant.
The common thread is a decision made at architecture stage, before the first school went live, to treat variation as configuration rather than code. That decision is harder to make than it sounds, because the pressure at launch is always to ship fast for the first customer, not to build for the fiftieth. The teams that get it right are usually the ones that have already maintained a forked product and do not want to do it again. For teams that have not been through that yet, it is the kind of architectural conversation worth having before the first line of code ships.
Why this is harder to defer in Ireland
Three properties of the Irish education market make the multi-tenancy decision more urgent here than in larger jurisdictions.
The total addressable market is smaller. Ireland has roughly 4,000 primary schools, 730 post-primary schools, and the ETB further education network. A platform that burns through its early adopters with per-school forks runs out of capacity to onboard new schools before it runs out of market.
The MIS landscape is fragmented differently from the UK. Aladdin dominates Irish primary schools. VSware and Compass split the post-primary space. There is no aggregator equivalent to Wonde to normalise the integration surface. That means the integration layer, the single largest source of per-school variation, has to be handled in the product architecture from day one.
School governance structures vary more across the system than outsiders expect. A Catholic voluntary secondary school, a community school under ETB governance, and a Gaelcholáiste (an Irish-medium post-primary school) operate under different reporting obligations even when they use the same curriculum. A product that treats "Irish post-primary" as a single tenant type will be forking code within its first five implementations.
Pro tip. Map the governance structures before mapping the features. The differences between a voluntary secondary, an ETB school and a community national school drive more configuration variation than any individual feature request. If the configuration layer can handle governance-level variation, it can handle everything below it.
What to do before the next feature request arrives
The sequence matters. Doing these out of order means building configuration on top of forks, which makes the problem worse before it gets better.
1. Audit the current codebase for per-tenant logic. Search for tenant IDs in conditional statements, per-school feature flags that are actually code branches, and any module that is loaded for one customer and not others. Count them. The number is usually higher than the team expects.
2. Classify each per-tenant item. Is it a genuine structural difference between school types (governance, MIS integration, compliance framework), or is it a preference that became hardcoded? Structural differences belong in the configuration layer. Preferences belong in user settings or tenant-level defaults.
3. Design the configuration tiers. Platform defaults, tenant-type overrides (primary, post-primary, FE, HE), tenant-specific overrides, user preferences. Define the inheritance rules before building any of them.
4. Migrate the highest-cost forks first. Start with the per-tenant logic that causes the most QA pain or the most support tickets, not with the most architecturally elegant refactor. The goal is to reduce release friction fast enough that the team sees the benefit before the next sales cycle adds more variation.
5. Change the intake process. Every new feature request gets classified at intake: configuration, integration mapping, or genuine new feature. If it is configuration, it ships through the configuration layer. If it is a new feature, it ships to everyone or it does not ship. That rule is harder to hold than to write, and it is the one that prevents the problem from recurring.
Frequently asked questions
At what point should we stop building per-school features and invest in a configuration layer?
If you are serving more than ten schools and more than a third of recent engineering work has been school-specific, the configuration layer is already overdue. The threshold is lower if you are selling into both Ireland and the UK, because the cross-market variation accelerates the problem.
Can we retrofit multi-tenancy onto a product that started as single-tenant?
Yes, but it is a migration, not a feature. The work involves separating tenant data, abstracting per-tenant logic into configuration, and rebuilding the deployment pipeline. It typically takes three to six months for a mid-complexity platform and should be scoped as its own project, not folded into a feature sprint.
How do we handle a large customer who insists on custom features that no other school needs?
Treat it as a commercial decision, not a technical one. If the customer is large enough to justify a dedicated configuration path, build it as a tenant-type override that could theoretically serve other customers of the same type. If it cannot be generalised, it belongs in a separate professional services engagement, not in the product codebase.
Does this apply to platforms selling into both primary and post-primary schools?
It applies more, not less. Primary and post-primary schools in Ireland operate under different MIS ecosystems, different curriculum structures, and different governance models. A platform that treats them as the same tenant type will fork faster than one that serves only one sector.
What is the difference between feature flags and a proper configuration layer?
Feature flags turn features on or off per tenant. A configuration layer defines how features behave per tenant. The first is a switch. The second is a set of parameters. Most teams start with flags and discover within a year that they need parameters, because the variation is not "does this school have the feature" but "how does this school's version of the feature work."
Whether you are building your first Irish school platform or refactoring an existing one, the architecture decision around multi-tenancy is worth making explicitly before the feature request backlog makes it for you.
Read next: how MIS integration, the single largest source of per-school variation in the Irish market, actually works in practice and what breaks in late August when it is not right. MIS Integration for EdTech: Why Late August Decides Whether Schools Stay With Your Platform
Or, if you want a concrete view of where your current architecture sits against the shared-core model before your next sales cycle adds more variation, we offer a complimentary Discovery Sprint assessment. Book a Discovery Sprint
