LMS and School Software Development Cost: Eight Modules, Priced
A school or training platform phase one runs 1,320 hours across eight modules. At $40 per hour that is $52,800, at $100 per hour $132,000, and about $85,800 at a $65 blended rate. The full span, every module at its minimum against every module at its maximum, is 910 to 1,820 hours.
The surprise in that list is which module is largest. It is not the learning content, the video player or the mobile app. It is the gradebook at 160 to 320 hours and fees at 160 to 300, and between them they decide whether the system is adopted or quietly worked around.
The reason is that both touch people outside the institution. A timetable that is wrong inconveniences staff. A fee balance that is wrong reaches a parent, and a parent who has been billed incorrectly once will check every invoice afterwards, which is the point at which your administrative saving reverses.
The ordinary failure here is not a failed implementation. It is a system that works correctly for the standard case and cannot express the forty percent of students who have a concession, a sibling discount, a mid-year start or an instalment plan — so those students get handled in a spreadsheet, and the spreadsheet becomes the real system of record.
Module | Worked example | Published range |
Discovery | 90 h | 60 to 120 |
Multi-tenancy, SSO and permissions | 130 h | 90 to 180 |
Student and staff master data | 170 h | 120 to 220 |
Admissions and counsellor CRM | 190 h | 140 to 260 |
Fees, concessions and instalments | 220 h | 160 to 300 |
Attendance and timetabling | 180 h | 120 to 260 |
Gradebook and report cards | 230 h | 160 to 320 |
Data migration | 110 h | 60 to 160 |
Total | 1,320 h | 910 to 1,820 |
Five people at roughly 600 useful hours a month puts that at three to four months.
Note what is not in the list: course content authoring, video hosting, proctoring and a parent mobile app. Those are real and they are separate decisions, each sized on its own. A platform that administers an institution and a platform that delivers learning content are different products, and a requirements document that merges them produces an estimate that is wrong for both.
160 to 300 hours, and the range is wide because the question "what do you charge" has far more answers than any institution initially admits.
List what actually exists in most fee structures. A base fee by grade or programme. Optional components — transport, meals, a lab, a trip — each with its own eligibility. Concessions: staff children, siblings, scholarships, hardship, each with a different rule and a different approver. Instalments, with due dates, late fees and part payments that have to allocate across components in a defined order. Mid-year joiners and leavers, pro-rated. And refunds, which have their own policy and their own approval.
Every one of those is ordinary and every one is a rule. A system with a fee amount and a due date cannot express them, so the exceptions move to a spreadsheet, and the spreadsheet is maintained by one person in the accounts office who becomes a single point of failure for the institution's revenue.
The design test is simple to state: can a parent with two children, on different programmes, one with a sibling concession, see one consolidated balance? If the answer requires a human to assemble it, the module is not finished.
140 to 260 hours, and it is the module whose value is easiest to measure because it sits directly on revenue.
An admissions pipeline is a sales pipeline with unusual properties. It has a hard deadline — a term starts whether or not the cohort is full — and the enquiry-to-enrolment path is long, multi-touch and involves people who are not the decision maker. A parent enquires, a student visits, a counsellor follows up, a document is missing, a fee deposit is due by a date, and the seat is held or released accordingly.
What makes this a build rather than a generic CRM is seat and cohort management. A general CRM tracks opportunities; an admissions system has to know that a programme has 60 places, that 48 are confirmed, 14 are provisionally held against unpaid deposits and 9 of those expire on Friday. Overbooking policy, waitlists and automatic release of expired holds are the operational core, and they are what a counsellor actually works from.
Document collection belongs here too, and it is more work than it appears: a checklist per programme, per applicant category, with verification status and an audit of who accepted what.
Worth separating, because the institution-facing system and the family-facing surface have different requirements and are often wrongly specified as one.
Staff use the platform all day and will tolerate density. Parents use it perhaps monthly, from a phone, often in a second language, and frequently under mild irritation because something has prompted them to log in. That audience needs very little: one balance, one way to pay it, attendance, results, and the next thing that requires their attention.
The failure mode is building a parent portal that mirrors the staff interface. It produces a surface with forty options where four were needed, and the measurable consequence is that the office keeps answering by phone — which is the cost the project existed to remove.
Decide the family surface separately and keep it ruthlessly small. In many institutions the honest answer is that it should not be an app at all: a message with a link to a payment page and a statement does more, more reliably, than an install nobody completes.
There is a measurable test for whether you got it right: count the calls the office still takes about fees and results after launch. If that number has not fallen, the family surface has failed regardless of how many people downloaded it, and adding features will not fix a thing people cannot navigate.
120 to 260 hours, and the upper end is where most institutions actually sit.
A timetable has to satisfy several constraints at once. A teacher cannot be in two rooms. A room has a capacity and sometimes a type — a lab, a workshop, a hall. A class has required contact hours per subject per week. Some subjects need consecutive periods. Some teachers are part-time with fixed availability. Electives split a cohort into groups that have to reconverge.
That is a constraint satisfaction problem, not a scheduling interface, and the difference in cost is large. Many institutions genuinely do not need a solver: a stable timetable set once a term by an experienced person, with the system holding and publishing it, is a legitimate and much cheaper answer.
Decide which you are before anyone quotes. The question to ask internally is how often the timetable changes and how painful each change is. If it is set in August and barely moves, buy the publishing half. If substitutions, room changes and absence cover happen weekly, the solver earns its hours — and the real requirement is not generating a timetable but regenerating one quickly when reality breaks it.
160 to 320 hours, the largest module, and the reason is assessment policy rather than arithmetic.
A grade is rarely one number. It is components — coursework, practical, examination — each weighted, sometimes with a minimum threshold per component that a total cannot compensate for. There may be grade boundaries that are set after results are known, moderation that adjusts a cohort, and a resit policy that replaces or caps a mark.
Then the record has to be defensible. A student or a parent will eventually query a grade, and the system has to show how it was derived: which components, which weights, which policy version, entered by whom and when. That is the same evidential discipline as any ledger, and it is why the module costs what it does.
Report cards add their own work, because they are a publishing problem with institutional formatting, multiple languages in many markets, and a sign-off step that has to be recorded rather than assumed.
There is a sequencing trap in the gradebook worth naming. Assessment policy usually is not written down anywhere complete, and the build is the first time anyone has had to state it precisely. That means the module doubles as a policy exercise, with teachers and academic leadership discovering they disagree about how a component threshold interacts with moderation. That discovery is valuable and it is also slow, so put the policy conversation before the sprint rather than inside it.
90 to 180 hours, and whether you need it is a question most single-site institutions answer wrongly in both directions.
A single school does not need multi-tenancy. Building it speculatively adds complexity to every query and every permission check for a second campus that may never open.
A group of schools does need it, and needs it from the start, because retrofitting tenancy into a system that assumed one institution means touching every table and every read path. The group case also brings the harder question: what is shared and what is not. A shared student record across campuses is useful when families move between them and a liability when campuses are separate legal entities. Shared staff records are usually right. Shared fee structures are usually wrong.
SSO belongs in the same module and is worth insisting on early, because institutions accumulate systems and a separate login for each is the most reliable way to make any of them unused. The same applies to leavers: a student or staff member who departs should lose access everywhere at once, and an institution without that is carrying accounts nobody has reviewed in years.
120 to 260 hours shared with timetabling, and the attendance half is deceptively simple.
The mechanics are easy: a register, a status per student per session, a total. What makes it work is everything around it. Who can change a mark after the fact, and is that change visible? A retrospective correction is legitimate — a student was present but arrived late, a medical note arrived the next day — and it is also the obvious route for a mark to be quietly altered. The record has to carry the original, the change, the reason and the person.
Then there is what attendance triggers. Many institutions have thresholds that affect eligibility to sit an examination, or that require a letter home, or that feed a funding return. Each of those turns a number into a consequence, and a consequence needs a rule, a notification and a record that it fired.
The device question matters too. Marking a register on paper and transcribing it later is where most attendance data goes wrong, so whatever surface a teacher uses has to work in the room, in the first minute, offline if the building's coverage is poor.
60 to 160 hours, and it is the one most often omitted from a comparison because it feels like a one-off task rather than a build.
What makes it work is not the volume of records but their consistency. Student records that exist in a previous system, a spreadsheet and a paper file, disagreeing about a date of birth or a guardian's phone number, need a reconciliation decision per field and a person to make it. Historical fees and grades are harder still, because they have to arrive in a structure the new system's rules can interpret, and old data rarely carries the attributes new rules require.
Decide what you are bringing: current students only, or history. Current year, or all years. The honest default for most institutions is current students with one year of history, and an archive of the rest left searchable but outside the operational system.
Run the migration twice before you run it once. A dry run into a staging environment, checked by the people who know the data — the registrar, the accounts office, a head of year — surfaces the disagreements that no technical validation can catch, because the errors that matter are the ones that are structurally valid and factually wrong. A guardian recorded against the wrong sibling passes every constraint in the schema.
Budget for the reconciliation conversations rather than just the transfer. The transfer is a week; agreeing what the data should say is the part with no fixed duration, and it is almost always the reason a go-live date moves. Starting it in parallel with the build, rather than after it, is the single most effective schedule decision available in this category.
A related question worth settling early: what happens to the old system. Running both in parallel for a term is a common instinct and a reliable way to ensure neither is trusted, because staff enter data in whichever is convenient and the two diverge within a fortnight. Pick a cut-over date, make the old system read-only on it, and keep it available for reference rather than for entry.
Not in the modules, which are published above.
They fail on fees, when the exception cases move to a spreadsheet and the spreadsheet becomes the system of record. They fail on timetabling, when an institution buys a solver it does not need or a publisher when it needed a solver. They fail on the gradebook, when a queried result cannot be reconstructed and trust in the whole system goes with it.
And they fail on adoption by teachers, which is the quiet one. Teaching staff judge a system by whether attendance and marks entry are faster than what they did before. A platform that adds two minutes per class per day has taken real time from people who have none, and they will route around it. Measure that specific interaction before anything else, because every other benefit of the system depends on the data those two minutes produce.
A phase one runs 1,320 hours across eight modules: discovery at 90 hours, multi-tenancy and permissions at 130, student and staff master data at 170, admissions and counsellor CRM at 190, fees and concessions at 220, attendance and timetabling at 180, gradebook and report cards at 230, and data migration at 110. That is $52,800 at $40 per hour, about $85,800 at a $65 blended rate, and $132,000 at $100. The full span across the eight is 910 to 1,820 hours.
Because "what do you charge" has more answers than any institution first admits: base fees by grade or programme, optional components each with eligibility rules, concessions for staff children, siblings, scholarships and hardship with different approvers, instalments with due dates and part payments that allocate across components in a defined order, pro-rated mid-year joiners, and refunds with their own policy. A system holding an amount and a due date cannot express those, so exceptions move to a spreadsheet that becomes the real record.
Only if your timetable changes often. Timetabling is a constraint satisfaction problem — teachers cannot be in two rooms, rooms have capacity and type, subjects need contact hours and sometimes consecutive periods, electives split cohorts — but many institutions set a timetable once a term and barely move it. In that case, a system that holds and publishes a timetable set by an experienced person is legitimate and much cheaper. The solver earns its hours when substitutions, room changes and absence cover happen weekly.
Course content authoring, video hosting, proctoring and a parent mobile app. Those are separate products with their own estimates, and merging them into one requirements document produces a figure that is wrong for both halves. The published figure prices the platform that administers an institution — admissions, students, fees, attendance, grades — rather than the platform that delivers learning content.
A single school does not, and building it speculatively adds complexity to every query and permission check for a campus that may never exist. A group does, and needs it from the start, because retrofitting tenancy means touching every table and every read path. The group case also raises what is shared: staff records usually should be, fee structures usually should not, and a shared student record is useful when families move between campuses and a liability when the campuses are separate legal entities.
For most institutions, current students plus one year of history, with everything older kept searchable but outside the operational system. The cost driver in migration is consistency rather than volume: records that exist in a previous system, a spreadsheet and a paper file, disagreeing on a date of birth or a guardian's number, need a reconciliation decision per field and a person to make it. Historical fees and grades are harder, because old data rarely carries the attributes new rules require.
Whether attendance and marks entry are faster than whatever they did before. A platform that adds two minutes per class per day takes real time from people who have none, and they route around it. That one interaction is worth measuring before anything else is optimised, because every other benefit of the system — reporting, parent communication, analytics — depends on the data those two minutes produce.
Vikas has around fifteen years of experience building software and now builds generative AI systems at Zyneto. His work covers retrieval augmented generation, agentic AI, knowledge graphs, AI memory, and the evaluation and guardrails that decide whether any of it is safe to put in front of customers. He has shipped enterprise copilots, document AI, chatbots and predictive analytics for e-commerce, fintech and marketing teams, and works day to day in Python, JavaScript and SQL. He follows multimodal models, business process automation and enterprise AI security closely, and mentors engineers moving into AI. He writes about architecture, inference cost and the failure modes that only show up at production scale.
Share your details and we will talk soon.
Be the first to access expert strategies, actionable tips, and the trends actually shaping the digital world. No fluff - just practical insights delivered straight to your inbox.
Dive into our blog and stay ahead of the curve with expert perspectives, future-ready trends, and tech tips written for decision-makers and doers alike.
