Optimizing for the returning visitor
Most guests are not new. Indexing and pre-resolving returning visitors is what turned a 60-second form into a sub-10-second confirmation, which is where nearly all the real-world time savings came from.
67%
faster check-in (60s to 20s)
<10s
returning visitor check-in
<7s
peak batch checkout
A full-stack visitor management platform for university housing, replacing paper forms and scattered spreadsheets.
Why it mattered
This one ran in production with real staff depending on it. Nothing teaches you about edge cases like a front-desk clerk using your software at 2am during move-in weekend.
The problem
Guest registration ran on paper forms and disconnected spreadsheets. A question as basic as "who is currently checked in?" meant digging through several systems, and peak traffic turned that into a queue at the desk.
What I built
- REST APIs with role-based access control separating staff and clerk permissions.
- React and Redux Toolkit front end that eliminated redundant data entry between check-in steps.
- Data models with optimized search paths so returning visitors resolve from a single lookup.
- Production deployment and operations on Render — I owned it from schema to uptime.
Inside the app
The dashboard front-desk staff actually worked from during move-in weekend. Click any screen to enlarge
Engineering notes
Batch operations for peak load
Checkouts cluster — everyone leaves at once. A batch checkout path handles the whole group in under 7 seconds rather than forcing the clerk through one record at a time.
Curious about any of this?
I am glad to go deeper on the architecture, the tradeoffs, or the parts that did not work the first time. That conversation is usually more useful than the README.