Moodle

Moodle LMS development, from empty server to first cohort

A working Moodle is a set of decisions about hosting, structure, access and grading. We make them with you, build the site on staging and launch it once real accounts have been tested.

  • Structure designed before install
  • Tested in every role
  • Your hosting, your data
Get a free quote See our work
What is included
  • Hosting and server stack
  • Categories, courses and cohorts
  • Authentication
  • Enrolment methods
  • Roles and capabilities
  • Gradebook and completion
Get a free quote Reply within one business day. NDA on request.
The problem

What goes wrong in a first Moodle build

Installing Moodle takes an afternoon. Deciding how it should be organized takes longer, and those decisions are expensive to reverse once teachers have built courses on top of them. Should each department get a category, or each program? Are learners enrolled by cohort, by self-enrolment with a key, or by a feed from your student records? Who may create courses, and who only teaches in them?

This page is about getting a new Moodle site right the first time. It is for training managers, IT leads and school administrators who have chosen Moodle (or inherited the decision) and need a team to turn a blank install into a platform people can log in to on day one. If you are still weighing platforms, start with our Moodle overview.

  • The structure was improvised

    Categories were created as requests came in. Two years later nobody can delegate administration cleanly, and reports by department need manual filtering because the tree does not match the organization.

  • Enrolment is a weekly chore

    Every intake means uploading spreadsheets and fixing typos. Learners who change class or leave the company keep their access, because nothing removes them automatically.

  • Completion was switched on late

    Courses ran for months before completion tracking and criteria were configured. Now the records are partial, and compliance asks for evidence the site never captured.

  • The server was sized by guesswork

    The site is fine with twenty users and stalls when a whole year group opens a quiz at once, because cron, caching and sessions were left on default settings.

What we do

What a Moodle build includes

A build is more than an install. These are the parts we design, configure and test as one piece of work.

Hosting and server stack

PHP, a MySQL, MariaDB or PostgreSQL database, a web server, HTTPS, the moodledata directory, cron and outgoing mail set up on infrastructure you control, sized for your peak hour.

Categories, courses and cohorts

A category tree that mirrors how you delegate and report, course templates with a consistent layout, and cohorts that let you enroll a whole intake in one step.

Authentication

Manual accounts, email self-registration, LDAP, OAuth 2 or SAML single sign-on, chosen per audience, with a password policy and custom profile fields that feed your reports.

Enrolment methods

Manual, self-enrolment with keys, cohort sync, course meta links and external feeds configured per course type, with rules for when access should end.

Roles and capabilities

Standard roles adjusted and new ones added, such as a department manager or an external assessor, assigned in the right context so nobody sees more than intended.

Gradebook and completion

Grade categories, aggregation and scales that match your marking scheme, plus activity and course completion criteria, badges and certificates learners can download.

Typical projects

Moodle sites we set up

01

A staff training portal

Mandatory courses assigned by department through cohorts, completion with expiry and recertification, manager reports, and sign-in through the company identity provider.

02

A school or college site

Categories by year and subject, courses created from a template each term, teachers and students enrolled from the student records system, and a gradebook parents can understand.

03

A training provider selling seats

A public catalog, paid or keyed self-enrolment, client companies kept apart with cohorts and groups, and certificates issued automatically when course completion criteria are met.

04

A rebuild of a tired site

A clean install on a current release with a new structure, into which we restore only the courses worth keeping, leaving years of clutter behind in an archive.

In depth

The decisions behind a new Moodle site

Structure follows delegation and reporting

We design the category tree by asking two questions: who should administer which part of the site, and how will you slice reports? Categories are contexts, so a role assigned at a category applies to every course beneath it. A tree built around departments makes "manager of Sales training" a single role assignment. A tree built around course type makes that impossible. Cohorts do the same job for people. One cohort per intake, team or client, synced to courses, turns enrolment into a membership change instead of a course-by-course task.

Pick enrolment methods per course type

Moodle lets several enrolment methods run in one course, and that is where confusion starts. We agree a short pattern book: compulsory courses use cohort sync, optional ones use self-enrolment (with a key where needed), programs made of several courses use meta links, and manual enrolment stays for exceptions. Each method gets an end rule, whether a fixed duration, an end date or removal when the user leaves the cohort. Suspending or unenrolling a leaver is also a choice, because it decides what happens to that person's grades and history in the course.

Completion and grades are configured before content

Completion tracking must be on at site level and in each course, with conditions on every activity and criteria for the course. If that happens after learners start, earlier work is not always counted the way people expect. So we set default completion conditions and build a course template first, then let your authors add content. The gradebook gets the same treatment: an agreed aggregation method, grade categories and a pass grade per activity, so that "passed" means the same thing across the catalog.

The server side of a calm launch

Three settings cause most early performance trouble. Cron has to run every minute, because enrolment sync, notifications and completion all depend on scheduled tasks. Sessions and the application cache should move off their default stores to something like Redis once you have real concurrency. And moodledata needs fast storage with room to grow, plus a backup that includes both it and the database. We load test with generated courses and users before launch, so the first exam is not the experiment.

Launch with a pilot

Go-live starts with one course and one cohort. We check logins, enrolment, a quiz attempt, a grade and a certificate with real accounts in each role, then open the rest of the catalog. Administrators receive a written guide for the tasks they will repeat: creating a course from the template, adding a cohort, resetting a course for a new term. When single sign-on or HR sync is part of the build, our Moodle integration page covers how that is wired, and the visual side is handled as Moodle theme development.

Process

Build stages from kickoff to go-live

  1. 1

    Requirements workshop

    We map audiences, course types, reporting needs and connected systems, and confirm hosting. The output is a written scope with milestones and a quote.

  2. 2

    Site blueprint

    Category tree, cohort plan, roles, enrolment patterns, completion rules and gradebook defaults are documented and signed off before anything is configured.

  3. 3

    Staging build

    We install Moodle, apply the blueprint, add the theme and plugins, and create course templates on a staging server you can log in to.

  4. 4

    Pilot and load test

    A pilot course runs with test accounts in every role, and we simulate peak usage to check cron, caching and database behavior.

  5. 5

    Launch and admin handover

    Production is switched on, the first real cohort is watched closely, and your administrators get training plus a written guide.

Deliverables

Delivered with your new Moodle

  • A documented category, cohort and role design
  • Course templates with completion already configured
  • Staging and production sites on your own hosting
  • Backups of database and moodledata, restore tested
  • An administrator guide for everyday tasks
FAQ

New Moodle site questions

How long does it take to get a new Moodle site live?
It depends on integrations and content more than on the install. A site with standard logins and a simple structure can be ready for a pilot within weeks, while single sign-on, data feeds and a custom theme add time. The quote sets milestones, so you know what arrives when.
Should we host Moodle ourselves or use a managed service?
Either can work. Self-hosting in your own cloud account gives full control over plugins, data location and cost, and needs someone to patch and monitor the server. We can set it up and look after it, or build on a managed host you have already chosen, provided it allows the plugins you need.
Do you create the course content as well?
We build the structure, templates and settings, and we can load existing material such as SCORM packages, documents, videos and question banks. Writing the learning content stays with your subject experts, who we train to use the course template so everything looks and tracks the same way.
How many users can Moodle handle?
Moodle runs sites from a few dozen learners to very large institutions. The limit is set by the server design more than by the software: concurrent quiz attempts, caching, the database and cron capacity. We size for your busiest hour and test it with generated load before launch.
Can learners sign in with their work or school account?
Yes. Moodle supports LDAP, OAuth 2 and, with a widely used plugin, SAML single sign-on, so accounts can be created on first visit and users skip a separate password. We choose the method your identity provider supports and map profile fields such as department or student number at the same time.
What should we prepare before a Moodle build starts?
A list of who will use the site, a sample of your courses, your reporting or compliance obligations, and access to the systems Moodle must connect to. If hosting exists already, we need access to that too. A short call usually fills any gaps before we write the scope.
Related

Moodle Theme Development

Moodle Integration

Moodle Maintenance & Support

Moodle Developer

Education & eLearning
Start a project

Planning a new Moodle site?

Tell us who will learn on it and what it has to report. We will come back within one business day with questions, a proposed structure and the next step toward a free quote.

  • Free consultation and quote
  • NDA on request
  • You own the source code
  • Reply within one business day
Prefer to talk first? Book a call WhatsApp wwc@worldwincoder.com
Add budget and timeline optional, helps us quote faster

This form is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.