Why a public site, an admin panel and an API are three applications

From the outside, Iqra Online Madrasa is a website. Students find it, read about the courses, and apply.

Underneath, it is three applications: a public Next.js site, a Next.js admin panel for the academic team, and a Laravel REST API that owns the data. They deploy separately. They can be worked on separately. Two of them the public never sees.

Clients ask us why. It is a fair question, because on the face of it we built three things where one would have done. Here is the reasoning, and the cases where we would not do it again.

One system, three jobs

The madrasa teaches Arabic and Islamic studies to adult learners across Bangladesh, most of whom study alongside a job. Before the platform existed, enrolment, course information and student support were handled by hand, across phone calls and spreadsheets. The team needed something that could grow with a national student base rather than something that would need replacing once it did.

Look at what the software actually has to do and it separates into three jobs that have almost nothing in common.

It has to persuade a stranger on a phone to apply. It has to let staff run an academic programme. And it has to hold the truth about courses, students and admissions.

Those are three different products with three different users, three different rates of change and three different definitions of "fast". We stopped trying to make one application good at all of them.

The public site is a reading experience

The public site has one job: a prospective student arrives, understands the programme, and applies.

That makes it a content problem, not an application problem. It is built as a statically rendered Next.js site so pages arrive quickly on a mobile network, which is how nearly every student reaches it. Content is Bengali-first, because the audience reads Bengali, and the typography and layout were designed around that rather than adapted to it afterwards.

Because it is a separate application, it can be exactly this and nothing else. It carries no admin code, no permissions logic and no dashboard framework. A visitor downloads what they need to read a page and apply, not the machinery for running a school.

That is a security property as much as a performance one. The application the public can reach has the smallest possible surface, because there is very little in it.

The admin panel is a working tool

The admin panel has the opposite brief. The people using it are staff, they are signed in, they are there every day, and they are not browsing — they are working.

It is built for that: role-based access so teachers and administrative staff see the parts of the system that belong to them, screens designed around lists and records rather than around persuasion, and course, student and content management the team can do without asking a developer.

It also gets to make assumptions the public site cannot. Staff sign in, so the panel can load more up front and be quicker afterwards. Nobody arrives from a search engine, so it does not need to be discoverable. The trade-offs that are wrong for a landing page are exactly right here.

Trying to serve both briefs from one application means every decision is a negotiation. Ship the admin machinery to the public and the public site gets heavier and more exposed. Optimise it away and the admin panel gets slower to use.

The API owns the truth

The Laravel API sits behind both. It holds courses, students, admissions and the enrolment workflow, and it enforces the rules about them.

The important part is not that the API exists. It is that the rules live in it and only in it.

An admission moves through a defined workflow. Whether that transition was triggered by a student applying on the public site or a staff member acting in the admin panel, the same code decides whether it is allowed. If the rules lived in the front-ends, we would have two implementations of the same policy, and they would drift. They always drift.

It also means the front-ends are replaceable. The public site will be redesigned; that is normal and healthy for a marketing surface. When it is, the admissions logic does not get rewritten, re-tested or re-broken, because it was never in there.

What the split costs

We are not going to pretend this is free.

Three applications mean three deployments, three sets of dependencies to keep current, and an API contract that has to be maintained between them. A change that touches all three is genuinely more work than the same change in one codebase — you have to think about ordering, and about what happens while one part is newer than another.

There is also more to hold in your head. A developer joining the project has three repositories to understand instead of one.

We think the trade is worth it here, and we would rather say plainly what it costs than pretend the architecture is a free upgrade. It is a decision, and decisions have prices.

When we would build one application instead

Most of the time, for most clients, we build one application. That is not a lesser answer.

We keep it as one when the software has a single audience, when there is no meaningful difference between the public and the signed-in experience, when the content is unlikely to outlive the front-end that displays it, or when the budget is better spent on getting a good product live than on an architecture that pays off in year three.

BeautyHub is a custom store, built as one application, and that is right for it. A corporate site with an enquiry form should be one thing. Splitting a small system into three is not sophistication; it is overhead you have volunteered for.

The test we apply

Before we split anything, we ask three questions.

Do these parts have different users? Not different screens for the same person — genuinely different people with different goals.

Do they change at different speeds? A marketing site that changes weekly and an admissions engine that changes twice a year are not comfortable neighbours.

Would we want to replace one without touching the other? If the answer is obviously yes, the seam is already there and we are only deciding whether to make it explicit.

For Iqra Online Madrasa the answer to all three was yes, so we built three applications. The platform is in production and serving students, and the team runs it themselves.

If you are being sold an architecture, ask the person selling it what it costs and when it pays off. If they cannot answer both, that is the answer.