A Moodle plugin in days: how it works and what done means

A small Moodle plugin used to take us one to two weeks and cost $300. The same plugin now takes two to three days and starts at $190. Bigger plugins moved the same way.

The work did not get sloppier. Most of the time on a small plugin was never spent writing code. It went to agreeing on a price, waiting for a slot, and back-and-forth after a late first demo. AI agents shortened the coding. Changing how we quote and demo shortened the rest.

This post shows where the days go, and what we check before we call a plugin done.

Where the time goes

Look at the black mark. In the old way, the client saw the plugin for the first time near the end. Every misunderstanding came out then, when it was most expensive to fix. Now the first demo video arrives within days, so a wrong assumption costs an afternoon instead of a week.

Step 1: a fixed price in minutes

You describe the plugin to our scoping assistant in plain words. It asks about the users, the Moodle version, and the systems involved, then gives a fixed price, a timeline, and what is and is not included. An engineer reviews every quote within one business day.

This step used to be calls and emails over several days. The assistant does not design the plugin or write code in the chat. Its only job is to understand the scope well enough to price it.

Step 2: design by a person

Before any code is generated, an engineer decides where the plugin lives and how it fits into Moodle:

• Plugin type. A block, a local plugin, a report, an activity module or an admin tool. Picking the wrong type is the most expensive mistake in Moodle development, because it decides how the plugin is backed up, where it appears and which APIs it can use.
• Data. Which tables, and whether the data belongs to a course, a user or the whole site. That decides the backup, restore and privacy work.
• Permissions. Which capabilities, given to which roles, checked in which context.
• Moodle versions. Which releases it must run on. A plugin for 4.5 LTS and 5.3 LTS has different constraints than one for 5.3 only.

This is the part AI tools are worst at. An agent will happily write a working block that should have been a report, or check a capability at system level when it should be course level. The code runs. It is still wrong. You find out months later when a teacher in one course can see data from another.

Step 3: agents write, a person reviews

With the design written down, AI agents draft the code and the tests. They are fast at the parts of Moodle development that are large but well defined: install.xml and upgrade steps, the settings page, language strings, a privacy provider for known tables, PHPUnit tests, Behat scenarios.

Every line is reviewed by a senior engineer before it ships. Review catches what agents get wrong on Moodle specifically: old APIs copied from outdated forum posts, a missing require_sesskey(), a SQL query built by string concatenation instead of placeholders, a string hard-coded instead of going through get_string().

Speed comes from the combination. The agent does in an hour what used to take a day. The reviewer knows, from years of Moodle work, what to look for in that hour of output.

Step 4: a demo, not a status update

Each build comes with a short demo video, screenshots, and the installable zip. You test it on a staging site with real teachers or students. Two rounds of changes are included in every quote.

What “done” means

Fast is only useful if the plugin keeps working after the next Moodle upgrade. So every plugin we hand over passes the same automated checks the Moodle community uses, from moodle-plugin-ci. Click a check to see what it catches.

On top of the automated checks, we go through a list that tools can’t fully verify:

• Privacy API. Since GDPR came into effect on 25 May 2018, Moodle plugins declare what personal data they store and implement export and deletion through the Privacy API. A plugin with no user data still declares that with a null provider. A plugin without a provider breaks your data requests without telling anyone.
• Capabilities and contexts. Every page and every web service checks the right capability in the right context.
• Backup and restore. If the plugin stores course data, course backups include it and restores bring it back. Without this, the first course copy at the start of term loses data.
• Upgrade steps. Every schema change has an upgrade step with a savepoint, tested on a copy of real data.
• Security basics. sesskey checks on every action, SQL placeholders, no eval(), output escaped. These come straight from the checklist Moodle reviewers used for the plugins directory (contribution checklist).
• Language strings through get_string(), ready for translation, with right to left layouts checked.
• Licence. GPL v3 or later, as Moodle requires for code that talks to core. You own the code and can hand it to anyone.

The plugins directory is now Moodle Marketplace, which replaced it in 2026 and now also lists paid plugins. A plugin that passes everything above is ready to submit there, and we can prepare the listing for you.

Why Moodle experience still matters with AI

Things are moving fast. Moodle ships a release every six months, PHP once a year, and the AI tools change monthly. In the last two years Moodle added an AI subsystem, moved to Bootstrap 5, moved web files into public/, and added React to core.

AI agents learn from public code, and most public Moodle code is old. Ask an agent for a Moodle plugin without guidance and you often get patterns from Moodle 3.x: YUI, $PAGE->requires->js() calls, Atto buttons, no privacy provider. It looks right and installs fine. It is already out of date.

So the useful setup is not “AI instead of a Moodle developer”. It is a Moodle developer who knows which patterns are current, which APIs are on their way out, and what breaks on upgrade, using AI to do the typing. That is how we can quote days instead of weeks without cutting the tests.

What it costs

Small plugins start at $190 and usually take two to three days. Standard plugins with their own data, permissions and backup start at $700. Larger systems are planned in milestones. Every quote is a fixed price for a written scope, paid before work starts. The full ranges are on the pricing section.

Sources

1. Moodle HQ, moodle-plugin-ci CLI reference.
2. Moodle HQ, Privacy API.
3. Moodle HQ, Plugin contribution checklist (legacy plugins directory process).
4. MoodleDocs, Plugins FAQ on Moodle Marketplace.
5. Moodle HQ, Releases and support dates.