Learning Management System
Ongoing development across a two-tier LMS platform
Unlike a from-scratch build, this meant inheriting a live LMS already serving customers across two pricing tiers, Enterprise and Small Business, and taking ownership of its ongoing evolution — new features, performance work, tier-specific behaviour, and the unglamorous but critical job of keeping a production system stable while people are actively using it.
Learning a live product from the inside
There was no blank slate — the LMS was already serving real customers across two tiers before I touched it. The first job wasn’t writing code, it was building an accurate mental model of how the whole thing actually worked: the data model, the tier boundaries, and the rough edges past decisions had left behind.
That groundwork is what let me move fast and safely on everything that followed — you can’t responsibly change a system you don’t understand yet, especially one customers already depend on.
- Reverse-engineered the existing architecture and tier logic before making changes
- Mapped where Enterprise and Small Business behaviour diverged in the codebase
- Treated the live product as the source of truth, not the original docs
Keeping Enterprise and Small Business honest
The tiers aren’t just a pricing page — Enterprise and Small Business customers get meaningfully different limits, permissions and features out of the same codebase. Keeping that boundary correct as the product grew was a recurring job, not a one-time feature.
Every new feature had to answer “which tier(s) does this belong to, and what happens at the boundary” up front, rather than getting bolted on afterwards.
- Built and refined tier-gated features and limits across Enterprise / Small Business
- Kept permission and feature boundaries consistent as new functionality shipped
- Avoided tier logic sprawling ad hoc across the codebase
Keeping a live product fast under real usage
A production LMS with active users doesn’t get the luxury of a clean-slate rewrite when something gets slow — you find the actual bottleneck and fix it without breaking what’s already working underneath customers.
That meant ongoing performance and scaling work: profiling slow paths, tightening queries, and shoring up the parts of the system that struggled under real load.
The unglamorous work that keeps a product trustworthy
Alongside new features, a steady stream of bug fixes and stability work kept the platform reliable for the people using it day to day — the kind of work that doesn’t show up in a highlight reel but is most of what keeps a live SaaS product trustworthy.
From inherited system to owned platform
Over time, feature development, tier refinement, performance work and steady bug-fixing turned a system I started out learning from scratch into one I could evolve confidently — shipping change after change to a platform real customers depend on every day.
Got a manual workflow worth automating?
This kind of focused, end-to-end tool is exactly what I like building. Let's talk about yours.