Moodle work for companies and education providers
Everything I build is Moodle-native: versioned plugins and themes, never edits to core, so your platform upgrades cleanly and your team can maintain it. Scope is agreed in writing, delivered on staging, and handed over with documentation.
What I do
LMS implementation
A Moodle platform set up on your cloud account and configured for how your organisation actually enrols, trains and reports. Suited to corporate compliance training, professional certification and course providers moving off a hosted product.
- Moodle 5.x on AWS or the cloud you already use, with staging and production, backups and a restore runbook
- Roles and permissions narrowed to what each team needs, documented capability by capability
- Enrolment, completion, certificates and notifications configured, not customised, wherever core does the job
- Mail, SSO and HR or CRM integrations where you need them
You receive
- A working platform your team has clicked through on staging
- Operations runbook and admin guide
- Role and capability register
- A handover call and 30 days of post-launch fixes
Custom plugin development
Activity modules, report plugins, blocks, local plugins, admin tools and web service integrations, written to Moodle's coding standards with the tests and CI the Moodle Marketplace expects. Suited to teams that need something core does not do and want it to survive the next upgrade.
- Moodle 4.5 LTS to 5.2, PHP 8.1 to 8.4, PostgreSQL and MariaDB
- PHPUnit and Behat for the behaviour that matters, run in GitHub Actions on every change
- Privacy provider, capabilities, language strings, backup and restore, upgrade steps: the whole surface, not just the happy path
- Marketplace submission if you want the plugin published
You receive
- A versioned plugin in a git repository you own
- CI configured and green
- README with installation, settings and known limitations
- Upgrade path for future Moodle releases
Themes and branding
Boost child themes that implement your brand guideline and stay upgrade-safe. Accessibility is built in from the first commit: contrast, keyboard navigation, focus management and screen reader behaviour are tested, not promised.
- Colour, type, logo use, login page, email templates and front page from your guideline
- Settings pages so your team can change content without a developer
- Dark mode, RTL languages and mobile layouts where you need them
- Behat coverage for every page a user interacts with
You receive
- A theme plugin with an override register listing every core template touched
- Screenshots and a settings guide
- Accessibility configuration and testing against common WCAG 2.1 AA failures, with written notes. Formal accessibility audit is not included.
Reporting and automation
Reports that match the spreadsheet your compliance or L&D team already files, scheduled exports, reminder and escalation mailers, and clean-up tasks that remove manual admin work.
- Custom report plugins or Report builder datasources, whichever fits
- Scheduled tasks with settings pages and logs
- Numbers checked against known data before you rely on them
You receive
- Reports in your format, on demand and on a schedule
- Mailers whose timing and audience are settings, not code
- Documentation of every rule the numbers follow
Delivery leadership
Owning a platform delivery, or leading the team that is building one. For organisations that have the budget and the people but need someone accountable for the plan, the sequence and the date.
- Requirements and BRDs, estimation, sprint planning and a milestone plan with acceptance criteria
- Day-to-day coordination of development, QA, UI/UX and infrastructure
- UAT run against the criteria agreed up front, with defects triaged with you
- Rehearsed production deployment with a tested rollback, then post-go-live support
- Written status and risk to stakeholders at every milestone
You receive
- A BRD, an estimate with its assumptions, and a milestone plan
- A delivery note per milestone and a signed acceptance record
- A release runbook and a restore procedure your team can execute
- Operations runbook, admin guides and a handover call
Upgrades, audits and support
Moving a platform to Moodle 5.x and PHP 8.4, reviewing an environment or a plugin someone else wrote, or keeping a platform healthy on a retainer.
- Upgrade planning, deprecated API fixes, plugin compatibility, the public/ document root change in 5.1
- Environment and security reviews with a written report and a prioritised fix list
- Performance work: caching, query optimisation, task scheduling
- Monthly retainer for updates, monitoring and small changes
You receive
- A written review or upgrade plan before any change
- Changes rehearsed on staging with a rollback
- A monthly summary on retainers
How work is shaped, and what it tends to cost in time
Not a rate card. Enough to know what to expect before the first call: scope is fixed and written down before any work starts, and larger builds begin with a paid discovery phase so the estimate is built on facts.
Most plugin, theme and reporting work
Price fixed per milestone, invoiced on acceptance.
- A written brief with what is in, what is out and the acceptance criteria, approved before work starts
- A fixed price per milestone, invoiced when the milestone is accepted on staging
- Changes to scope are written up and priced separately, never absorbed silently
For platform builds and migrations
Fee credited against the build. The documents are yours either way.
- Three to five days, fixed fee, before any build is quoted
- Output: a written brief, an estimate with assumptions, a risk list and a recommended milestone plan
- The discovery fee is credited against the build if it goes ahead with me; the documents are yours either way
After launch, or for an existing platform
Dots are the monthly summary. Unused hours roll over once.
- A monthly block of hours for updates, monitoring and small changes, with a written summary each month
- Unused hours roll over one month
- Priority response on incidents
Working inside your team
Ticks are weekly invoices. Minimum two weeks.
- For teams with their own backlog and review process
- Weekly invoicing, timesheet on request
- Minimum engagement of two weeks
Typical project sizes
| Shape | Examples | Typical duration |
|---|---|---|
| Small | A report to a spec, a theme change from a brand guideline, a mailer, an upgrade of one plugin | One to two weeks |
| Medium | A new plugin with tests and CI, a full Boost child theme, an integration with an HR or CRM system | Three to six weeks |
| Large | A platform implementation on your cloud with roles, branding, reporting and handover; a migration to Moodle 5.x | Six to twelve weeks, after discovery |
Durations are elapsed time with review cycles included, not billable days. Rates are discussed on the first call and depend on scope; I invoice in USD, GBP, EUR or INR.
Fixed scope, short milestones, written handover
- Call
Thirty minutes on what you need and what you already have. If Moodle core covers it, I will say so, and show you on the live demo.
- Brief and quote
A written brief: what is in, what is out, milestones and how we will know each is done. A fixed price per milestone, or a day rate for open-ended work.
- Build and review
Each milestone ends with a walkthrough on staging and a delivery note listing what changed, what to test and what is still open.
- Handover
Runbooks, guides, repository access and a handover call. Post-launch fixes included; support after that on a retainer if you want it.
I work in IST with afternoon overlap for UK and EU teams and morning overlap for the US East Coast. See the hours.