Case Study
De-risking a scaling event before the school year
A fixed-scope Rails performance audit for an EdTech startup bracing for 15,000 students at once — delivered inside the estimate.
A venture-backed EdTech CTO came to me nervous about a number on a calendar: 15,000 students logging in at the start of the school year, on an app that had never really had traffic. He wanted to know if it would hold.
The company
An EdTech web app for project-based learning — teachers clone a project, assign it to a class, and students log in to work on it. Mostly students, by volume. A Rails monolith with some AngularJS front-end pieces, inconsistently versioned, originally built by an offshore shop and inherited by the CTO, who'd come on "to save this thing."
What I did
He'd already done the first-pass work himself — fixed some N+1 queries, added basic caching — and wanted someone with more depth for a real audit before the launch. His two fears, in his words: the servers can't handle the traffic, or the hosting costs go astronomical. We scoped it as a fixed 5–10 hour performance audit against that deadline.
I got the production database dump running locally, reconciled a Postgres version mismatch, and pulled the slowest actions through their APM to profile them. The headline finding was reassuring: the app was largely free of the major red flags I usually see in a codebase like this. There were tweaks to make — the Redis caching configuration needed adjusting or swapping for Memcached, which was straightforward — but no structural disaster lurking ahead of the launch.
I delivered the report and landed in the middle of the estimate. That's worth saying plainly: the value of a clean audit is partly that it tells you not to panic, and partly that it does so without burning your budget.