Salon Chain Management Platform
A B2B SaaS that brings a salon chain's daily operations - appointments, sales, staff, customer history - into a single platform.
- Role
- Frontend Developer (solo)
- Stack
- Next.js · TypeScript · MobX · Tailwind CSS
A sector with a digital gap
For years, beauty salons have been run mostly on Excel sheets, paper appointment books, and disconnected tools. That works for a single salon. It breaks down quickly when you're managing dozens of branches across one of Turkey's largest chains.
Our client was in exactly that position: appointments lived in separate systems across branches, customer history didn't move between locations, staff shifts were handled apart from everything else, and sales and stock reports had to be put together by hand. A product was being built to bring all of this into one platform - we joined the project as it was getting close to launch.
“Not just to finish the code base we inherited, but to take ownership of it and ship it.”
Our Approach
We joined a frontend that had already been in development for months. The first week we just read the code: which module lives where, why each decision was made, which parts needed cleanup. Writing code without a plan on a project this size would have pulled us into the wrong places fast.
We ran two streams in parallel: shipping new features, and making the existing code maintainable. Not sequentially - interleaved. Before starting on a new module, we cleaned up its files, then built on top of them.
Technical Decisions
Breaking up 4500+ line module files
The code base we inherited followed a one-big-file-per-module pattern. A single appointment module had its UI, business logic, API calls and state management all packed into a file over 4500 lines. The previous developer had a view that component-based architecture "isn't always the right answer" - but at this size, working solo, the structure wasn't sustainable. We split each module into three layers: reusable components, logic gathered into custom hooks, and MobX stores. As a result, pieces like the date picker, customer card and status badge from the appointment module could be reused as-is across the sales, staff, and CRM modules.
API integration through MobX
One of the decisions made early in the project was to use MobX for state management - that part was already in place by the time we joined. We aligned the API layer with that pattern, handling requests directly through the stores. We worked closely with the backend lead to design the endpoints and methods we needed; the frontend integration layer was ours to build.
A mixed approach to forms
The forms in a salon management product vary widely: creating an appointment is complex (time conflicts, staff availability, package selection), customer registration is medium, adding a quick note is trivial. Rather than forcing everything through one library, we picked the right tool per case. For complex forms we leaned on React Hook Form for its validation and performance. For simpler ones, we kept state manually with MobX or useState - which made the code easier to read and avoided pulling in a dependency where it wasn't earning its place.
Multi-level permissions
A salon chain has layered user roles: head office manager, branch manager, cashier, therapist, receptionist. Each sees different pages, can touch different parts of customer data, and is allowed different actions. We built this on two layers: route guards block users from pages they shouldn't see at all, while component-level checks hide buttons and fields on pages they can see but only partially use. With both layers in place, "the wrong person can't get to the wrong place" doesn't depend on a single point of enforcement.
From the UI
Outcome & Impact
By the time our work wrapped up, the product was ready to ship. The backend lead took over the deployment; the product went live with one of Turkey's largest beauty salon chains as its first customer.
The frontend we inherited ended up as something new features could be added to in days, where shared components moved freely between modules, and where performance didn't get in the user's way.
Have a similar project?
If you're building a complex B2B application or need to clean up an existing code base, let's talk.
Get a Quote