We are a small team of Moodle developers writing custom extensions for organisations that depend on the platform every day. Our clients are universities, training companies and e-learning businesses that have outgrown the standard feature set and need software built specifically for the way they teach, assess and administer their courses.

Our work is deliberately narrow: Moodle plugin development, custom themes and carefully scoped core changes, all written against the Moodle API rather than bolted on around it. That focus is what keeps the code maintainable and, above all, upgrade-safe, so a new Moodle release does not turn into a rewrite.

If you have a requirement Moodle cannot satisfy out of the box, or an existing plugin that no longer fits, we can take it from specification through to a supported extension. This page covers custom Moodle development; for connecting Moodle to other systems see Moodle integrations, and for day-to-day configuration and maintenance see Moodle admin services.

What we build

Custom plugins

We build the full range of Moodle plugin types: activity modules that add new ways to teach and assess, blocks that surface information inside a course, reports that turn platform data into something usable, and admin and local plugins that change how a site is configured and operated. Question bank types, filters, authentication and enrolment plugins fall in the same bucket.

Every plugin is architected on the Moodle API and built to the platform's coding guidelines, so it behaves like a first-party component. It respects roles and capabilities, uses Moodle's forms, events, privacy API and backup/restore, and installs cleanly through the standard plugin administration screens.

Moodle theme development

Design and implementation of responsive Moodle themes that align with your brand and your learners' needs. We can build a theme from scratch or refine an existing one: improving typography, navigation and accessibility, and cleaning up the parts that fight the platform.

Wherever possible we extend the core theme system with a child theme instead of forking it. That keeps upgrades predictable and cuts the amount of code you have to own.

Core modifications and utilities

Some requirements cannot be met cleanly with a plugin, for example a data export that spans several subsystems or a bespoke grade calculation. In those cases we implement controlled core modifications, isolated and documented so they can be re-applied after an upgrade, and we build standalone utilities to automate administration, migrate data or script recurring tasks.

How we work

Every engagement follows the same honest shape, adjusted to the size of the job:

  1. Discovery. We start by understanding the requirement, the constraints and how the feature will actually be used, including the Moodle version you run and any local customisations.
  2. Estimate. You get a written scope with assumptions and an estimate before any code is written, so we agree on what is being built.
  3. Build. We develop on the Moodle API and to Moodle's coding guidelines, keeping the code inside the plugin structure rather than patching core wherever a plugin will do.
  4. Test. We test against stable and LTS branches, and cover the upgrade path so nothing depends on a version you are about to leave.
  5. Deliver and support. We hand over the code, install or upgrade instructions, and a short set of notes on anything you need to know. Ongoing maintenance is available but never assumed.

Why TuchSoft

TuchSoft publishes and maintains its own Moodle plugins: for example local_numicon, a local plugin that adds icon sets to Moodle through the platform's icon API. Because we ship and support plugins publicly, we work inside Moodle's conventions, review culture and release cycle every day, not only during client projects.

That has a practical effect on your project. We know which APIs are stable and which move, where the platform is heading, and how to write code that a future Moodle release will not break. You can browse what we maintain on the Moodle plugins portfolio.

If you are still deciding whether a requirement needs a plugin at all, Extending Moodle sets out the options. For recent platform changes worth planning around, see What's new in Moodle 5.3.

Frequently asked questions

Will the plugin survive future Moodle upgrades?

Yes, that is the design goal rather than an afterthought. We follow Moodle's coding guidelines, prefer the plugin APIs over core patches, and test against stable and LTS branches. Where a core change is unavoidable, we isolate and document it so it can be re-applied after an upgrade.

Can you take over a plugin someone else built?

Yes. We audit the code, identify anything that will not survive the next upgrade, bring it in line with current Moodle standards and then maintain or extend it. If the original plugin is unmaintained, we can also take ownership of its future releases.

Do you work on an existing Moodle site, or only new ones?

We work on existing installations as well as new ones. We can operate as an isolated development resource, work directly with your in-house team, or hand over cleanly once the work is done. Access to a staging copy of the site is useful but not required to start.

How does an engagement start?

Usually with a short conversation about the requirement and the site behind it, followed by a written scope and estimate. Nothing is built until that scope is agreed, and small jobs can start from a fixed brief without a long discovery phase.