Until recently each Akadesk product named its applications after whatever it happened to build first: frontend, frontend-admin, platform-frontend, portal. Nothing was wrong with any single name. The problem was collective — knowing one product told you nothing about where to look in the next.
The four surfaces
- platform-web — the product's own marketing site, and where an institution signs up
- tenant-web — the public site each institution gets, and where its learners sign up
- webapp — the application itself, behind auth
- admin-web — the platform operator's console across every tenant
A fifth, mobile, exists where there is a Flutter app. The split falls along a real line rather than an arbitrary one: the first two are public, indexed and want server rendering, so they are Next.js. The last two are behind auth and never indexed, so server rendering buys nothing and they are React with Vite.
Why it was worth doing
The same question — where does a student sign up? — now has one answer in every product. So does where the marketing copy lives, which port an app runs on, and which host serves it in production. That consistency is what makes a set of products feel like one suite rather than a set of acquisitions.