Lernicle Platform

As a Product Engineer for Lernicle, the fundamental challenge was that the platform serves dozens of different elementary schools on a shared infrastructure. In school management, student privacy and parental records are sacred. If a software engineer writes a quick query and forgets to filter by school ID, one school could accidentally see another school's private student information, grades, or disciplinary logs. I wanted to design a system where data separation was impossible to bypass by mistake an at the same time keeping the interface fast and responsive during busy morning school hours.

Here is an understanding of what was broken, how I fixed it, and the results.

§1. Automatic School Data Isolation

On shared platforms, relying on developers to remember to add school filters to every single database query is a recipe for privacy leaks. Human error will eventually happen and in an education product, that is completely unacceptable.

To guarantee that schools can never see each other's data:

• ›I implemented a strict mechanism ensuring that the schoolId is required for every single request; if the ID is missing, the request is instantly blocked and will not go through.
• ›I configured automated code rules that block any direct, unfiltered database queries from ever being committed to the codebase.
• ›I also integrated robust identity security checks that actively flag user logins originating from unknown locations or unrecognized devices to prevent unauthorized access.

Because of this built-in isolation, school privacy is guaranteed by default, eliminating the risk of accidental data leaks before code even reaches production.

§2. Flexible Two-Level Staff Permissions

Different schools have different organizational structures: one school might need custom roles for volunteer teaching assistants, while another wants front-desk staff to handle attendance without seeing sensitive tuition and billing details. At the same time, our own operations team required high-level oversight across the platform.

To handle these varying requirements cleanly:

• ›I created a two-tier permission system that separates platform-wide administrative roles from individual, school-defined staff roles.
• ›I gave school principals and owners the ability to create custom staff roles and adjust exact viewing permissions without needing help from our engineering team.
• ›I optimized the permission verification checks so they run in milliseconds without adding lag to daily classroom operations.

This gave schools the exact administrative control they needed, while keeping our platform management simple

§3. Securing Student Files and Report Card Downloads

Schools generate and store hundreds of sensitive documents every term, from report cards and attendance sheets to medical clearance forms. In early versions, file storage relied on basic web links that could potentially be shared outside the school.

To secure sensitive school documents:

• ›I built a dedicated file verification gate that checks the requester's active school membership before granting access to any file.
• ›I set up temporary, expiring access links for document downloads, ensuring that even if a link is forwarded or copied, it stops working after a short window.
• ›I added automated rate limiting to prevent bulk scraping or unauthorized downloading of school records.

Now, student files and school documents remain completely private, and parents and teachers can safely download report cards knowing their family data is protected.

§4. Keeping Accounts Safe on Unfamiliar Devices

For sensitive actions like changing a password or approving a payroll run, simply being logged in is not enough. School accounts are often used on shared office computers and an attacker with a stolen session could quietly do real damage. At the same time, staff are usually invited into a school's workspace by email and we did not want activation to depend on temporary passwords that could sit exposed in an inbox.

To protect accounts beyond the login screen:

• ›I built a device trust gate that recognizes the devices a user normally signs in from. A brand-new device can still log in, but high-risk actions like password changes stay blocked for a short cooldown period until we are confident it is really the owner.
• ›I made the system send an instant email alert whenever important account details change, showing the exact time, location, and device used, along with an emergency "I didn't do this" button that locks the account immediately.
• ›I replaced temporary passwords with secure, expiring invitation links, so joining a school never relies on plaintext credentials sitting in an email or exposed to guessing.
• ›I added stricter rate limits around login and other sensitive routes, and required bank account verification before any money-moving action can be unlocked, to blunt brute-force attacks and fraudulent payouts.

This closed the account-takeover gaps that plain login checks could never cover, giving schools and families real protection for sensitive information.

§5. Neutralizing Hidden Malicious Code Before It Reached Production

While reviewing routine code updates one day, I spotted a piece of malicious code that had been deliberately disguised to slip past reviewers. If it had reached the live system, it could have secretly downloaded and run attacker instructions, hidden its traffic on public networks, and altered system settings to capture passwords.

To stop the attack in its tracks:

• ›I blocked the pull request, flagged it as a supply-chain attack, and coordinated a clean-up across the three affected code repositories in careful, tracked commits—stripping out the malicious payload, resetting tampered configuration, and auditing our dependencies.
• ›I hardened the review process so configuration files are explicitly validated for their content, making it impossible for a payload like that to hide inside a routine-looking diff again.
• ›I made sure every audit log strips out personal and sensitive fields before anything is stored, so our own security records never become a second place for private data to leak.

The malicious code was neutralized before it ever reached production, and checking for this kind of threat is now a standard part of every code review instead of a rare, periodic audit.

§6. Building a Billing System That Sets Schools Up Instantly

Schools sign up from different countries, pay in different currencies, and expect their plan to start working immediately. Onboarding a new school used to mean a string of manual configuration steps, and promotional discounts could accidentally last forever if someone forgot to switch them off.

To make sign-up and billing effortless:

• ›I built a flexible billing engine that handles international payments, automatically pricing plans in each school's local currency and region.
• ›I designed discounts to expire automatically after a set time, so promotions can never silently become permanent.
• ›I made the system automatically calculate charges when a school grows beyond its plan, like adding extra students.
• ›I added a central plan gatekeeper that enforces subscription limits, such as the number of students, staff seats, and storage, before any new data is saved, so no school can ever quietly exceed what they pay for.

Now a new school is onboarded through one simple flow—plan, billing, data region, then invitations with no manual database work and every account is correctly configured from day one.

§7. Making All Four Portals Feel Like One Product

Lernicle is really four websites: a public marketing site, a dashboard for school owners, a portal for teachers, and an AI tutor for students. Because they had been built by different people at different times, every one of them worked differently behind the scenes, and engineers had to relearn a whole new system every time they switched between projects.

To make the frontends consistent and fast to build on:

• ›I established one shared set of standards and updated all four portals to follow it, starting with centralized, typed routing so no route is ever a random hardcoded string scattered through the code.
• ›I standardized how components are structured—every reusable piece gets its own folder with presentation, types, tests, and subcomponents each in their place—so the shape of the code is identical everywhere.
• ›I enforced a clean separation between the interface and the logic, moving all data fetching and validation into dedicated hooks so a screen stays purely presentational.
• ›I made state live at the lowest layer that can own it, and required every async feature to explicitly handle loading, success, error, and empty states, so a slow network never silently renders a blank page.
• ›I backed these rules with automated checks that run before code is committed, auditing accessibility (like minimum tap sizes and keyboard support) and flagging any component that breaks the standards.

As a result, new engineers ramp up quickly no matter which portal they touch, and quality problems are caught before they ever reach a code review.

§8. Snappy Classroom Dashboards and Quick Attendance

During the morning rush between 7:30 AM and 8:30 AM, thousands of teachers and administrators log on simultaneously to mark attendance, review bus schedules, and process morning check-ins. If the dashboard stutters or takes several seconds to load student rosters, it creates real friction in school halls.

To keep the platform fast under heavy morning traffic:

• ›I overhauled our data fetching to load classroom rosters in small, efficient batches, displaying student cards instantly instead of waiting on the entire school database.
• ›I added intelligent local caching for school schedules and staff directories, so pages switch instantaneously without repetitive network requests.
• ›I optimized form inputs so teachers can mark attendance with one tap, saving time and keeping classroom lines moving smoothly.

This made the platform feel light and snappy, keeping morning check-ins painless even on older classroom computers or unstable school Wi-Fi.

§9. Reliable Zero-Downtime Deployments

Because schools depend on Lernicle throughout the school day for attendance and parent communications, taking the system offline for updates would disrupt daily school operations. Our automated testing also ran on shared cloud servers that hit usage limits during busy periods, leaving teams waiting on results.

To ensure continuous uptime and safe releases:

• ›I created an automated deployment pipeline that runs thorough automated tests on permissions, database scoping, and authentication before releasing any update.
• ›I designed database changes to roll out in non-breaking phases, allowing new features to launch smoothly without ever taking the platform down.
• ›I moved our automated tests onto dedicated infrastructure, eliminating usage limits completely and making the build process roughly four times faster.
• ›I added a human approval step where every production release is posted to our team chat and waits for a lead engineer to approve before going live, so each deployment is double-checked and auditable.
• ›I centralized our passwords and system settings into a secure vault that injects secrets only at the exact moment they are needed, so no developer machine or code repository ever stores exposed credentials.

As a result, our engineering team can ship regular updates and security patches with confidence, knowing schools will experience uninterrupted service throughout the school year.

§10. Keeping the Platform Stable Under Pressure

As the platform grew, our automated testing servers started running out of memory and crashing randomly, and a single compromised application could once have threatened the entire machine. When things do break, every minute of downtime matters to a school mid-morning.

To keep everything stable and recoverable:

• ›I fixed the crash-prone test infrastructure by limiting how many tests run at once, giving the build process more memory, and finding the hidden bugs in our testing code that were causing it to freeze indefinitely.
• ›I moved our application storage onto a faster, globally distributed network, hardened our server security so a compromised application could not take over the whole machine, and configured internal logging to track errors without violating data-privacy boundaries.
• ›I wrote and maintain a simple emergency action plan for critical outages, so if a bad update ever breaks the live site, engineers instantly revert to the last working version, redeploy it, and run a health check to confirm everything is back online.

This eliminated the memory crashes and frozen test runs at their source rather than working around them, and it means our team can respond to the worst-case scenario calmly and quickly, with downtime kept to a minimum.