Custom Moodle Development

Some requirements are bigger than one plugin. A workflow that spans enrolment, delivery and reporting; a theme that has to match a brand system; a site that needs to behave differently for three kinds of user. That is custom development, and the risk in it is always the same – building something that works today and cannot be upgraded next year.

What we take on

• Theme and interface work. Almost always a Boost child theme rather than a from-scratch theme, because child themes inherit core’s fixes and from-scratch themes inherit its bugs forever. Brand colours, typography, navigation simplification, and cutting the clutter learners do not need.
• Workflow changes. Enrolment journeys, approval steps, assessor allocation, and the “why does it take six clicks to do this” problems that make staff avoid the system.
• Reporting. Where core reports and the report builder cannot answer the question, a purpose-built report that can – with the query written so it does not fall over on a large site.
• Site behaviour. Role and capability architecture, category structure, and the configuration decisions that determine whether a Moodle stays manageable at scale.
• Performance work. Profiling a slow site and fixing the actual cause, which is often a single plugin or a missing index rather than the server.

How we work

Staging first, always. Nothing goes to production that has not run somewhere else first, and every change ships with a way back. Work is delivered in reviewable pieces rather than one large drop at the end, so you can see it before it is finished and change your mind while changing your mind is still cheap.

You get a written scope before we start – behaviour, assumptions, Moodle version target, and what is explicitly out of scope. If we hit something during the build that changes the shape of the work, you hear about it when we find it, not in the final invoice.

Custom development is not always the answer

A meaningful share of the requests we get are solved by configuration, by a maintained community plugin, or by changing a process that grew around a limitation that no longer exists. We check those first. It is a smaller invoice and a much smaller long-term maintenance burden, and telling you so is the whole reason to hire a specialist rather than a general web agency.

Related services

Custom development usually overlaps with plugin development, integration, and ongoing maintenance – because anything custom needs re-testing at each major Moodle version. If you host with us, that testing is part of what managed hosting includes.