Uptrend — Self-Care.
Booked. Managed. Delivered.
A full-stack, three-sided self-care booking marketplace — 6 apps and 3 web portals built simultaneously, with real-time calendar sync across partners and experts, commission + subscription monetization, and live on both the App Store and Play Store.
What is Uptrend?
Uptrend is a three-sided self-care booking platform — think Fresha, built from the ground up. Users discover and book salon, spa, wellness, and fitness services. Partners (business owners) manage their locations, staff, and schedules. Experts (service providers) receive bookings, manage their calendars, and track earnings — all in real time, across every surface.
This was the most architecturally complex project we've delivered. 6 native mobile apps, 3 web portals, a real-time availability engine syncing partner and expert calendars simultaneously, and a dual monetization layer — all shipped, live on the App Store and Play Store.
Nine surfaces. One coherent product.
Self-care booking platforms fail at the same place every time — the supply side. Users churn when expert availability is inaccurate, when bookings don't sync, or when partners can't manage their business from their phone. Uptrend was built to fix all three, simultaneously.
- Existing platforms had static availability slots — no real-time sync when an expert's calendar changed mid-day
- Partner-side tools were web-only, desktop-heavy — salon owners couldn't manage bookings from their phone
- Three-sided marketplaces require three separate permission models, notification flows, and data views — most agencies scope one and bolt on the others
- Commission + subscription billing on the same platform required a dual ledger model most backends aren't designed for
- App Store and Play Store require separate builds, separate review processes, and separate compliance — across 6 apps simultaneously
- Real-time availability engine — expert calendar changes propagate to user-facing booking slots in under 2 seconds
- Purpose-built mobile apps for both Partner and Expert — not responsive web wrappers, native apps with role-specific UX
- Three fully isolated permission models sharing a single backend — user, partner, and expert see entirely different data from the same API
- Dual monetization layer: per-booking commission deducted at settlement + recurring subscription billed monthly per partner location
- All 6 apps shipped simultaneously to App Store and Play Store — coordinated release with shared component library reducing build time by 40%
Built to feel premium at every screen.
Every screen was designed with the end-user in mind — someone on the move, often distracted, who needs information fast and decisions to be obvious.
Built for three different users. Feels like one product.
Every feature had to work across three permission models, two platforms, and nine surfaces without inconsistency. That constraint shaped every architectural decision.
Expert calendar changes — blocked slots, lunch breaks, emergency cancellations — propagate to user-facing booking availability in under 2 seconds. No stale slots, no double bookings.
Discover salons, spas, wellness centers, and fitness studios. Browse expert profiles, check live availability, and book in under 3 taps. Post-service reviews and rebooking built in.
Business owners manage locations, service menus, pricing, staff assignments, and booking calendars from their phone. Real-time booking notifications and revenue dashboard included.
Service providers see their daily schedule, receive booking alerts, mark services complete, and track earnings — all in a purpose-built interface designed for in-salon use.
Commission deducted automatically at booking settlement. Monthly subscription billed per partner location via Razorpay recurring payments. Both revenue streams tracked separately in the admin panel.
Full platform visibility — partner onboarding, expert verification, booking volume, commission revenue, subscription health, dispute management, and content moderation from a single dashboard.
One codebase strategy across nine surfaces.
Shared component library between mobile apps cut development time significantly. Shared API layer across all nine surfaces meant one backend serving three permission models cleanly.
One backend. Three permission models. Nine surfaces.
The architectural constraint that shaped everything: a single API had to serve radically different data to three user types, in real time, with no permission bleed between them — while syncing calendar state across partner and expert simultaneously.
- Expert availability stored as a time-slot graph in Redis — each slot has state: OPEN, BOOKED, BLOCKED, HELD (5-min hold during checkout)
- Any calendar mutation (expert blocks time, partner adds holiday, booking confirmed) publishes an event via Socket.IO to all subscribed user sessions browsing that expert
- Slot HELD state prevents double-booking during payment processing — auto-releases after 5 minutes if payment not completed
- Conflict resolution: partner-level blocks always override expert-level availability — hierarchy enforced at the engine level, not application level
- Role-scoped JWT tokens — user, partner, and expert tokens carry different claim sets and are validated against separate middleware chains
- Single API codebase with role-based route guards — no separate backend per user type, no duplicated business logic
- Data isolation enforced at the query layer — partner queries are automatically scoped to their location IDs, experts to their assignment records
- Superadmin role has read access across all scopes with explicit write permission flags — no accidental cross-scope mutations
- Booking settlement triggers commission deduction via atomic ledger transaction — partner credited net amount, platform credited commission in same operation
- Monthly subscription billed via Razorpay recurring payment links — failure triggers grace period logic with automated retry and partner notification
- Two separate revenue ledgers in PostgreSQL — commission ledger and subscription ledger — consolidated in superadmin reporting view
- Refund logic handles commission reversal correctly — partial and full refunds recompute commission and adjust both ledgers atomically
What nine surfaces taught us about product architecture.
Multi-sided platforms don't fail on features. They fail on the invisible connective tissue — availability sync, permission isolation, and coordinated releases across surfaces.
- 01Real-time availability accuracy — a confirmed booking on the partner side wasn't instantly removing the slot from user-facing search, causing double-booking attempts
- 02Permission bleed between user types — early builds had edge cases where partner-scoped API calls could return data from other partner accounts under certain query conditions
- 03Coordinating App Store and Play Store reviews for 6 apps simultaneously — review timelines varied by up to 5 days, causing platform inconsistency at launch
- 04Dual monetization ledger integrity — commission and subscription revenue needed to be independently auditable, but both fed the same partner payout flow
- Slot HELD state introduced at checkout initiation — booking attempt locks the slot before payment, confirmed booking finalizes it. Double-booking structurally impossible
- Query-layer scoping via middleware-injected context — every database query receives a scope object from the auth middleware, not from the calling code. Permission bleed eliminated at the data layer
- Phased release strategy — user apps released first, partner and expert apps released 48 hours later after user-side store approval confirmed. Coordinated via feature flags
- Separate ledger tables with a unified view — commission and subscription remain independently auditable, consolidated only at the reporting layer via a materialized view
“Most agencies would scope this as three separate projects with three separate backends. We built it as one product with one API and nine surfaces. That decision alone saved the client four months of development time and made the platform maintainable by a single engineering team post-launch.”
Three user types, real-time sync, dual monetization, and nine surfaces — this is the kind of product where architecture decisions made in week one determine whether you ship in six months or eighteen. Let's get them right.