CLMS — Teaching Business Management System
Learning Business Management System

Overview
CLMS (Course & Lesson Management System) is a fully self-developed international teaching management system. As students and courses grew, the old way started to break: missed or wrong class times, miscalculated amounts, time-consuming monthly reports, scattered student status, complex leave and make-up, hard-to-maintain pricing, and international timezones with DST adding scheduling complexity.
No off-the-shelf product fit, so we built our own — turning the fragmented teaching and operations rules into one unified domain model.
The Challenge
The system had to keep answering: who teaches today? how many lessons done? how much is due? who starts when? who is on leave? who needs a make-up? who needs follow-up? what is this month’s report?
Off-the-shelf tools — spreadsheets, generic SaaS, school systems — could not unify these rules in one verifiable model.
Solution
Around domain modeling, I built the backbone Course → Class → Student → Enrollment → Lesson (Lesson is the standardized object linking teaching records, scheduling, leave, make-up, and billing).
Billing supports monthly (fixed fee, unaffected by a single leave) and per-lesson (by actual teaching time); pricing supports per-student rates, historical price retention, and natural-month activation without backdating; leave and make-up are distinguished on teacher vs student sides; multi-currency — mainly IDR, also USD, AUD, CNY, MYR, THB and more — with per-student currency, date-based rates, and historical rate retention.
Domain Backbone
Architecture Layers

Implementation
I owned requirement analysis, business-rule modeling, domain modeling, product design, architecture decisions, AI-assisted implementation, and testing.
AI was leverage for engineering, not the product decision-maker — more precisely, AI-assisted Engineering: understand the problem, design the solution, use AI to implement, apply human judgment, iterate.
Key Capabilities
- ›
Business Discovery
Finding productizable rules inside a real business.
- ›
Domain Modeling
Turning fuzzy business rules into a testable domain model.
- ›
Product Thinking
Balancing business goals, complexity, and cost.
- ›
SaaS Architecture
Designing system layers around an evolvable model.
- ›
AI-assisted Engineering
Using AI to raise engineering efficiency, with humans owning key decisions.
- ›
Financial Precision
Precise modeling and testing of billing, FX, and historical prices.
Deliverables
A SaaS product exploration driven by a real business, carrying business rules all the way into product and engineering: the domain model and core rules are live in actual use, with courses, billing, leave, make-up, and reporting forming a working loop.
Takeaway
This project reinforced my belief: the value of complex business work often lies not in lines of code but in turning real rules into a verifiable model.
Tech Stack
Domain Layer
Service Layer
Repository Layer
HTTP / UI Layer
Engineering Note
Business rules are decoupled from the UI / HTTP layer, leaving room for future SQLite → PostgreSQL migration and single-user → multi-role expansion.
Next Step
Good products often start from a real business’s “can’t calculate, can’t remember, can’t reconcile” — turning fuzzy rules into a testable domain model.
Contact