,800, themes from $900, senior engineers at $85/hr. Upgrade-safe code, PHPUnit/Behat tested, fixed quotes. Free scoping call.">

Moodle™ Development by Senior Engineers

Plugins, themes, and integrations built to Moodle's own coding guidelines — tested against 4.5 LTS, safe through every upgrade, and priced before we start.

Sternfast builds custom Moodle plugins from $1,800, Boost child themes from $900, and integrations at $85 per hour — senior engineers in Nashville, working US-wide. Everything follows Moodle's coding guidelines, ships with PHPUnit and Behat tests against 4.5 LTS, and survives upgrades: no core hacks, ever. Scoping calls are free and quotes are fixed.

Custom development, done the boring way

Most "custom Moodle work" we inherit is a core hack with a plugin's name on the folder

Someone edited course/lib.php directly. It worked, the invoice got paid, everyone moved on. Two years later an upgrade overwrote the changes and nobody could remember exactly what they were. We build the other kind of customization — plugins and themes that use Moodle's extension APIs, so version upgrades are boring instead of terrifying.

That's really the whole pitch. Moodle has a genuinely good plugin architecture — activity modules, local plugins, blocks, auth and enrol plugins, admin tools, report plugins, theme layers — and almost anything you want changed can be done inside it. When a developer says they need to "modify Moodle itself," what they usually mean is that the plugin API route is more work and they'd rather not. We'd rather. It's tedious for a week and then it's safe for a decade.

Book a free 20-minute scoping call

Tell us what you want built. We'll tell you which plugin type it should be, roughly what it costs, and whether you actually need it. We reply within 1 business hour.

What we build

Plugins, themes, integrations — priced in the open

Custom plugins

from $1,800

Activity modules, local plugins, blocks, admin tools, custom reports. Built to the Moodle coding guidelines, with PHPUnit tests, Behat acceptance tests, and the Privacy API implemented — the same bar the Moodle.org plugin directory sets.

Plugin pricing details

Themes

from $900

Boost child themes: your brand, your SCSS, targeted Mustache template overrides — and nothing else touched. Brand-and-colors starts at $900; a full custom design runs $3,500–$8,000 depending on how far from Boost you want to go.

Theme pricing details

Integrations & web services

$85/hour

SSO (SAML2, OAuth 2, LTI 1.3), SIS enrollment sync, HR-system provisioning, custom REST endpoints on Moodle's external functions API. Scoped fixed-price where possible; hourly in 10-hour blocks ($800) where it isn't.

Describe your integration

Rescue & performance

$85/hour

Inherited a hacked core or an abandoned plugin? We untangle customizations back into upgrade-safe plugins, profile slow pages (it's usually mdl_logstore_standard_log grown to tens of gigabytes), and get you onto a supported version. Pairs well with a migration if you're changing hosts too.

Get a rescue assessment
WorkSternfast priceWhat's included
Brand theme (Boost child)from $900Logo, palette, fonts, login page, favicon — upgrade-tested before delivery
Custom pluginfrom $1,800 (market band: $1,500–$10,000)Written spec, build, PHPUnit + Behat tests, Privacy API, docs, git handover
Full custom theme$3,500–$8,000Custom layouts, Mustache overrides, accessibility pass
Hourly engineering$85/hr — $800 per 10-hour blockSenior engineers only, itemized work log, no hand-off to juniors

Engineering standards

What "upgrade-safe" actually means (and how to check for it)

Anyone can promise upgrade-safe. Here's what the promise cashes out to in practice — in enough detail that you can audit any developer's work, including ours.

Themes: a child of Boost, never a fork of it

A safe theme declares $THEME->parents = ['boost']; and changes only what it must: SCSS through the pre/post hooks, plus individual Mustache templates copied into the child theme's templates/ directory only when CSS genuinely can't do the job. Every template you override is a file you now maintain against core changes, so the count matters. Our brand themes typically override two or three. We've inherited "custom themes" that forked all of Boost and overrode two hundred.

Plugins: their own tables, their own upgrade path

A real plugin keeps its schema in db/install.xml (built with the XMLDB editor, not typed by hand), migrates it with versioned savepoints in db/upgrade.php, defines capabilities in db/access.php, and never writes to core tables like mdl_grade_grades directly — it goes through the gradebook API like everything else. Strings live in language packs so the plugin is translatable. None of this is exotic; it's just the parts most shops skip because they're tedious.

Testing: CI against the versions you'll actually run

Every plugin goes through moodle-plugin-ci on GitHub Actions: PHP_CodeSniffer with the moodle-cs ruleset for the guidelines, PHPUnit for the logic, Behat for the click-paths — against Moodle 4.5 LTS (supported into October 2027) and the current 5.x release. Worth knowing when you plan your own upgrades: 4.1 and 4.4 both left security support on December 8, 2025, and 5.0 reaches end of support in October 2026. If a developer's CI matrix still targets those, that isn't caution — it's embalming.

Privacy: the API most shops treat as optional

Every plugin that stores user data implements the \core_privacy providers — metadata declarations, data export, deletion. It's required for the plugin directory, and it's what makes a GDPR or FERPA data-subject request answerable in an afternoon instead of a research project. If your learners include minors, this is not negotiable; our compliance page covers how we handle it.

Free to steal: before accepting any custom Moodle work, run git diff between the vendor's delivery and a clean Moodle release of the same version. If core files changed, you didn't buy a plugin — you bought a permanent maintenance obligation.

Buyer's guide

How to evaluate any Moodle developer — including us

Use this on every shop you talk to. It takes ten minutes and filters out most of the market.

  • Can they show shipped code? Plugins in the Moodle plugin directory, or at minimum public GitHub repos. Screenshots of admin pages prove nothing; commit history proves a lot.
  • Do they test against 4.5 LTS and current 5.x? Ask which versions their CI matrix covers. A blank look here ends the conversation.
  • Do they write PHPUnit and Behat tests? Ask to see one Behat feature file from a past project. Shops that write them can produce one in thirty seconds.
  • Will they put "no core modifications" in the contract? If they hedge with "sometimes it's necessary," ask for one concrete example. There almost never is one.
  • Do they implement the Privacy API by default, or is GDPR/FERPA compliance an upsell?
  • Who owns the code, and where does it live? The right answer: you, in a git repository you control, with documentation, on the day of handover.
  • Do they quote fixed prices after scoping? Open-ended hourly on a well-specified plugin usually means they haven't specified it.

We wrote this list because we pass it. But genuinely — take it to our competitors too. A good plugin from another shop beats a bad one from us, and if someone else passes the checklist and charges less, hire them. We'd rather meet you later for the hosting.

Run us through the checklist — book a free scoping call

Plugins from $1,800, themes from $900, hourly $85. Replies within 1 business hour, or call (615) 396-7139.

How an engagement runs

Free scoping, fixed quote, milestone payments

1. Scoping call — free, 20 minutes. You describe the problem. We tell you which plugin type it maps to, whether an existing community plugin already does 80% of it (this happens more often than either of us would like), and a realistic budget range on the call.

2. Fixed quote. A short written spec — what it does, which Moodle versions it targets, what "done" means — with a fixed price attached. No spec, no invoice.

3. Milestones. Larger builds split into demo-able milestones on a staging site. You pay per milestone, and you can stop at any of them and keep everything shipped so far.

4. Handover. Git repository, install and admin documentation, the CI configuration, and a walkthrough call. Then either your team maintains it, or a Care Plan covers updates when new Moodle versions land.

One honest caveat: we don't take every job. If your request is really a SCORM tracking problem or a hosting problem wearing a development costume, we'll say so on the scoping call and point you at the cheaper fix.

Questions we actually get

Moodle development FAQs

How much does a custom Moodle plugin cost?

Ours start at $1,800; the wider market runs roughly $1,500–$10,000 depending on complexity. A simple block or report lands near the bottom of that range; an activity module with grading, backup/restore support, and mobile compatibility lands near the top. You get a fixed number after a free scoping call, not a surprise afterward.

Can you customize Moodle without breaking future upgrades?

Yes — that's the entire point of Moodle's plugin architecture. Themes extend Boost as child themes, functionality ships as plugins with their own database tables and upgrade scripts, and core files stay untouched. We test against Moodle 4.5 LTS and the current 5.x release before delivery, and we put "no core modifications" in writing.

Can you fix or extend a plugin another developer built?

Usually. We start with a short paid code review — a few hours at $85/hr — to find out whether it's extendable or whether it hacked core, then quote from there. About a third of rescue jobs turn out cheaper to rebuild properly than to patch, and we'll tell you which yours is before you commit to anything.

Can you integrate Moodle with our SIS, HR system, or SSO?

Yes. Common builds: SAML2 or OAuth 2 single sign-on, LTI 1.3 tool connections, and enrollment sync from an SIS through Moodle's web services or a scheduled task. If your other system has an API, Moodle can talk to it.

Who owns the code when you're done?

You do. Everything is delivered in a git repository you control, with documentation and CI configuration. No license fees back to us, no lock-in — if you leave, the code goes with you.

How long does a typical build take?

A brand theme: one to two weeks. A small plugin: two to four weeks including tests. Integrations vary with the other system's API — that's usually the long pole, not Moodle. Delivery dates go on the milestones in the written quote.

Next step

Tell us what you want Moodle to do

A 20-minute scoping call costs nothing and ends with a plugin type, a budget range, and an honest answer about whether you need us at all. Themes from $900, plugins from $1,800, senior engineers at $85/hour.

Book your free scoping call

We reply within 1 business hour. Prefer the phone? (615) 396-7139. Full rates are on the pricing page.