Fitting into an institution's way of working
Getting oriented in the first two weeks
Your developer begins on a test site restored from a recent production backup, never on the live one. They list every additional plugin and its source, compare core with a clean download of the same release to detect edits, check that cron and scheduled tasks are healthy, and read through your authentication and enrollment setup. The result is a short report for your LMS administrator and IT lead. It usually contains a surprise or two, such as an abandoned plugin holding up the next upgrade.
Working through your change process
Most institutions have change control, and we fit into it. Requirements come from the LMS administrator or a learning technologist, often as a short specification with roles and capabilities named. The developer answers with a design note: which plugin type, what tables and capabilities it adds, what happens on uninstall. Code is delivered to your repository, installed on the test site, then promoted to production by whoever holds that responsibility on your side. We can do the deployment if you prefer, in a window you approve.
Standards, review and automated tests
Moodle code is run through the Moodle code checker before review. Database changes go through install.xml and versioned upgrade steps, never ad hoc SQL. Where logic matters, such as grade calculations or enrollment rules, we write PHPUnit tests, and Behat scenarios for key user paths when the plugin justifies it. A second Moodle developer on our side reviews each pull request for capability checks, parameter cleaning and output escaping, which is where security problems usually hide.
The rhythm of the academic year
Development is heaviest in the months before teaching starts. During term the developer focuses on fixes, reports and preparation, and avoids releasing anything that changes quizzes or grading while assessments are open. Major version work is planned for breaks. For the detail of how that is rehearsed, read about our Moodle upgrade service.
What a good fit looks like
Your LMS administrator should find the developer easy to talk to and hard to rush into a shortcut. Listen for questions about contexts, roles and what happens at upgrade time. Those are the signs of someone who has looked after a Moodle site for longer than one project. Then read their first pull request with your IT lead. Clean capability checks, language strings in place of hard-coded text and an upgrade step for every database change tell you more than an interview does.