Extending the platform without forking it
Not every academy needs every feature, and shipping rare features to everyone makes a product worse for the people who do not use them. Modules are how TKDS LMS grows sideways instead of getting heavier.
Why modules exist
A learning platform accumulates requests. One academy needs a very specific attendance report. Another needs an integration with a system nobody else uses. A third needs a workflow that only makes sense in their country.
Shipping all of that into the core would give every customer a heavier product, a longer settings page and more surface to get wrong. So rarely-requested capability becomes a module: a self-contained package that only exists on the installs that asked for it.
The result is that your platform stays exactly as complex as your needs, and no more.
What a module can add
A module is a real extension, not a settings preset. It can bring its own:
Screens — a new page in the admin, instructor or student area, with its own sidebar entry and icon.
Server routes — its own endpoints, mounted under the module’s own namespace.
Database tables — its own migrations, run when the module is installed.
Translations — its own strings, in every language your platform runs.
Because a module renders through the platform’s own design tokens, it inherits your theme and right-to-left layout automatically. A module never looks bolted on.
Installing, updating and removing
- 01
Discover or redeem
The Plugins screen in your admin lists what is available to your academy, plus anything you already own. Some modules are public; others are private and unlocked with a redemption code.
- 02
Install
One click downloads the package, installs it, runs its database migrations, and registers its screens. Its sidebar entries appear immediately.
- 03
Enable and disable
A module can be switched off without being removed. Off means invisible — the same rule as every other feature in the platform.
- 04
Update
New versions appear on the same screen with their changelog. Updating is a click, and each module has its own release cycle independent of the core platform.
- 05
Remove
Uninstalling deletes the module’s code and its interface. Its data is kept. Reinstall it later and everything is where you left it.
Why removal keeps the data
Licences lapse and renewals get delayed. Deleting a customer’s records because an invoice was late would be indefensible, so we do not. The tables stay; only the code goes.
Zero modules, zero traces
An academy with no modules installed sees no sign the system exists — no empty marketplace tab teasing purchases, no placeholder menu, nothing.
This is the same principle as the core feature switches, and it is deliberate: your staff should never have to learn to ignore parts of their own admin panel.
When a module is the right answer
If you need something the platform does not do, there are three honest outcomes and we will tell you which one you are in:
It is a switch you have not found. The most common answer. Costs nothing and takes a minute.
It belongs in the core. If a request would help most academies, it goes into the product for everyone rather than being sold back to you.
It is genuinely specific to you. Then it becomes a module, scoped and quoted, and it lives on your install without making anyone else’s platform heavier.
What we will not do is describe your requirement as impossible because it is inconvenient, or sell you a module for something that should have been a checkbox.
Need something the platform does not do yet?
Describe the workflow and we will tell you which of the three answers it is.