Redlab Studio — Replacing manual membership administration
A studio management system that replaced spreadsheets and paper-based workflows for memberships, subscriptions, classes, and attendance.
Replacing manual membership administration
While working at Redlab Studio, I designed and engineered an internal web application to replace the spreadsheets, paper forms, and manual checks used to manage memberships and subscriptions.
The system brought client records, memberships, payments, classes, and attendance into one place, while making information available that had previously been difficult to retrieve.
I developed the system over roughly a year, evolving it alongside the studio's day-to-day operations.
The problem
Membership administration was largely manual.
Registering members, checking subscriptions, recording payments, and tracking attendance all involved repetitive data entry and manual verification.
The existing process worked, but common workflows took more time than necessary and left more room for manual errors.
The studio also had limited visibility into its own data. Questions such as how many memberships were active, how much revenue had been generated, or which classes were performing well often required manually going through records.
The challenge was not simply to digitize the existing records, but to make the recurring workflows faster and more reliable while making the resulting data useful.
Designing around the studio's workflow
The interface was designed around the environment where it was actually used: reception, where staff moved quickly between checking members, taking payments, and preparing for upcoming classes.
Bottom navigation and swipeable sheets for quick, one-handed reception workflows.
Persistent navigation and side drawers that preserve the current search and list state.
The goal was to keep staff inside the current workflow rather than sending them through separate pages for every task.
A typical interaction became:
Member details, subscription information, payment forms, and class information could be opened without losing the current list or search state.
The interface also prioritized quick visual scanning. Membership status, payment state, and other important information used clear hierarchy and restrained status colors so reception staff could understand a member's state without reading through the full record.
Making recurring classes manageable
The studio's schedule was built around recurring classes, but individual sessions could still change.
A class might run every Saturday while one occurrence needed to be cancelled, moved, or changed without affecting the rest of the schedule.
A recurring class needed to behave as a series while individual sessions remained independently editable.
I modeled the calendar around recurring series and individual occurrences, allowing changes to be applied to one session or to future occurrences without rewriting the entire schedule.
This kept the calendar aligned with how the studio operated instead of forcing staff to manage recurring classes as a collection of unrelated events.
When the first architecture became a constraint
The first version was built directly around SvelteKit's server-side actions and route structure. This was enough to get the initial workflows working, but as the product grew, more features became independent of individual pages.
Features that should have been reusable across the application were increasingly tied to specific routes. The architecture was starting to shape the product rather than simply support it.
I refactored the application around a separate API layer using Hono, allowing the frontend to consume application operations independently of the page structure.
The refactor created a clearer boundary between the interface and application logic and made reusable features easier to extend across the product.
Outcome
The application became the primary system for managing the studio's clients and memberships, replacing the spreadsheets and paper records used before it.
Staff could manage client information, subscriptions, payments, classes, and attendance from one place. Owners could also access current and historical information about memberships, revenue, and classes without manually combining records.
After about a year of development, the system covered the studio's day-to-day needs and remained in use during the rest of my time there.
Reflection
This was my first substantial development project after transitioning into software development. Building and maintaining a system used in a real operational environment taught me to think about product and engineering decisions as part of the same system.
Design around actual workflows rather than predefined features. The most useful improvements came from removing repetitive manual steps and connecting information staff previously had to manage themselves.
Recognize when implementation details start constraining the product. The API refactor became necessary when route-specific logic made otherwise reusable features harder to build.
Looking back, I would make some architectural decisions differently today. Working through those constraints taught me how to recognize when a system's structure is becoming a bottleneck and how to change it without losing sight of the product.
