Scaling a campus-access product from 20K to 200K MAU: a hardware-software PM diary

Between March 2023 and August 2024 I worked as Associate PM at SpaceBasic in Bangalore. The product was a campus-living operating system — accommodation, mess, complaints, and (the part this post is about) physical access control. Over those eighteen months the user base went from roughly 20,000 monthly active users to 200,000. Most of that growth came from one large rollout — an autonomous access system at Woxsen University that combined facial recognition, physical flap barriers, and a custom leave-management module.

The temptation when writing about scaling is to pretend it was driven by a strategy. It was not. It was driven by the realization, somewhere in the second month, that software PMs imagine hardware as just another integration, and then a barrier closes on a student's bag at 8:47am and you discover what reliability really costs.

The brief

Woxsen wanted to replace their existing manual gate-pass system — students approached a security desk, presented an ID, and signed a register — with something automated. The constraints were specific. It had to clear 1,500 students through a single gate during morning and evening peaks. It had to recognize students reliably enough that false rejections did not cause a queue. It had to allow staff overrides without bypassing the audit log. And it had to handle the edge case that defined the project: legitimate students whose facial biometric was failing for environmental reasons (sunlight, masks, a new haircut).

On paper this is a familiar PM problem. In practice it is three different products in a trenchcoat: a facial recognition pipeline running on edge devices, a leave-management workflow used by parents and wardens, and a hardware integration with industrial-grade flap barriers manufactured by a third party who had never integrated with a SaaS product before.

What the user numbers actually meant

We hit a 10x in monthly active users in roughly fourteen months, but the headline obscures what the metric was measuring. SpaceBasic counts an MAU as any student or staff member who interacts with the product at least once a month — and at a residential university, the access gate touches every member of the population every day. The Woxsen rollout alone added approximately 8,000 students who used the access system 60+ times a month. The MAU growth followed naturally from winning institutional partnerships, which is closer to enterprise sales than consumer-product growth.

This matters because the internal metric I actually optimized for was not MAU. It was "successful first-attempt entries" — the percentage of access attempts that cleared the gate on the first try, without staff intervention. That is the metric that determines whether the gate becomes a queue.

What software PMs do not appreciate about flap barriers

Flap barriers have minimum cycle times. The mechanical sequence — open, clear, close — takes about 1.8 seconds end to end on the units we used, and you cannot meaningfully shorten it without changing the hardware. That means the maximum theoretical throughput of a single gate is roughly 33 entries per minute. At a 1,500-student peak, you have to either spread the peak or add gates.

Once you understand this constraint, the entire facial-recognition latency budget changes. You do not need a sub-200ms recognition pipeline — the barrier cannot move that fast anyway. What you need is a recognition pipeline that completes within the 1.8-second mechanical cycle of the previous user, so the system is already locked-and-loaded when the current user arrives. We deliberately tuned for 800–1,200ms recognition, sacrificing edge-case accuracy for predictability.

The second non-obvious thing is that the failure mode of a barrier is much worse than the failure mode of a login screen. A failed login is an inconvenience; a failed barrier is a queue that backs up across the street while a 19-year-old with a backpack stands there blocking it. The product decision that came from this: every recognition failure had to fall back to a manual override that the security guard could invoke in under three seconds, and every such override had to be logged with the reason. Logging the reason was the part that made the product useful for the warden later — it produced data we could use to retrain the recognition model.

The leave-management module that was not on the roadmap

Two months into deployment, a parent called the warden because their daughter had walked out of campus during a class and they wanted to know if and when. The warden checked our access logs and could confirm — but the warden then called us asking for a feature: parents should be able to see their child's exit/entry events themselves, at least during the period the child was on approved leave.

This is the kind of request that gets dismissed as scope creep. It is not on the roadmap; it has unclear user demand; it introduces a privacy surface (parental access to student location data) that the product does not currently handle. We built it anyway, because the warden was describing a real workflow that existed regardless of whether we supported it. Without product support, the warden was manually forwarding screenshots from the access dashboard to parents over WhatsApp.

The leave-management module that resulted was deliberately scoped narrow: parents could see entry/exit events for their student only during a leave window approved by the warden, and only for the duration of that window. No live tracking. No outside-of-leave visibility. The audit log captured every parent view. This shipped in about six weeks and became one of the features the institution specifically referenced when they renewed.

Three decisions that mattered more than they looked

• · The override always logs a reason. A free-text field with a 280-character cap, defaulting to one of five common presets. This single field produced the dataset we used to retrain the recognition model for edge cases (masks, sunlight, beard growth). Without the reason, the override becomes a black hole that eats every interesting failure.
• · The recognition latency budget is set by the slowest component, not the fastest. We tuned the software to match the barrier, not the other way around. A faster pipeline would have felt impressive but produced no user benefit, because the gate itself was the bottleneck.
• · Parent access is a permission, not a feature.The leave-management module worked because parents were not getting a new capability; they were getting a scoped, audited view into data the warden already had. Framing it as a permission boundary made the privacy story coherent and the institution's legal team comfortable.

What I would do differently

Three things, in order of magnitude.

First, I would have built the override-reason taxonomy before deploying the recognition pipeline. We added it as a hot-fix after the first two weeks of operation, which means we lost a fortnight of high-value failure data. The taxonomy itself was the product asset; the recognition model was downstream of it.

Second, I would have separated the "identity check" pipeline from the "authorization check" pipeline architecturally. We bundled them, which meant a failure in identity (a student whose face was not recognized) was indistinguishable in the codebase from a failure in authorization (a student who was correctly identified but had a hold on their account). Splitting these would have made the override workflow simpler and the audit log more useful.

Third — and this is the broader lesson — I would have invested more time observing the gate in person, earlier. There were three or four product decisions I made from the dashboard that I would have made differently if I had spent two morning peaks at the gate watching students fail recognition. Software PMs working on hardware-adjacent products tend to over-trust the dashboard and under-trust their eyes. The dashboard tells you what happened. Standing at the gate tells you why.