All Works
Full-stack engineer: build and support/Nov 2025 – present

Salon operations app

The system a Delhi salon runs its day on

Staff log every service on their phones; the owner approves, pays and sees profit. It has run the salon's day since November 2025, across 141 commits of changes driven by how the staff actually work.

Private: staff and payment data stay in the salon.For: A salon in Delhi
141
commits since November 2025
1
summary read per day, instead of every log
5th to 5th
the salon's pay cycle, kept exactly

// The Problem

Services were logged on paper and WhatsApp, which meant disputes over who did which client, payroll worked out by hand, and no view of profit.

It had to run on the free database quota: when the day's reads ran out, approvals and check-ins stopped.

// How It's Built

  1. Staff phone

    Log a service, check in at the salon

  2. One transaction

    The log entry and the day's summary change together

  3. Owner approval

    Online payments matched against the bank statement

  4. Payroll and profit

    Read from daily summaries, never from every log

Every write updates the day's summary in the same transaction, so screens read one small document per day.

// Decisions & Trade-offs

  • 01

    Approvals tied to real money

    Entries over a threshold, or logged away from the salon, need the owner. Online payments are matched against the bank statement, and a service shared between staff is grouped so one payment covers it.

  • 02

    Reads as a design constraint

    Screens read daily summary documents that every write keeps in step, cached reads cover slow-changing data, and any read of a large range asks first.

  • 03

    Pay rules belong to the business

    The salary cycle runs from the 5th to the 5th because that's the salon's rule. The code follows it rather than a calendar month.

  • 04

    A plain, fast interface

    An early version with gradients, glows and animation felt slow and cluttered in daily use. It was rebuilt with a system font, neutral colours and one primary action per screen.

// Problems Worth Telling

  • 01

    The quota ran out mid-day

    Heavy reads exhausted the free daily quota and blocked approvals until it reset. That drove the summary-document redesign and a rule that large reads ask before they run.

// Quality

  • Write paths are tested against the Firestore emulator with Playwright, including location checks for attendance, and never against production data.

// Where It Stands

  • In daily use by the salon's staff and owner since November 2025.

// Stack

Next.jsReact 19TypeScriptFirebase Auth and FirestorePWAPlaywrightFirestore emulator
Next case studyLinkord

Building something similar?

Let's talk