Case study · 2026 · Chandigarh Tri-City

One honest beauty platform, designed as a system.

A face scan and a few questions give people a plan in four lists, including what to skip. Salons, clinics and spas get a free toolkit and the customers who need them. Product, data model, brand and go-to-market, designed together.

Systems designProduct & UXDesign system as codeBrand identityGo-to-market
Overview02

Beauty advice usually ends in a longer shopping list. This one ends in a shorter one.

Betta Beaut is a two-sided platform for the Chandigarh Tri-City — Chandigarh, Panchkula, Mohali, Zirakpur and Kharar. Customers get a free three-minute scan and an honest plan, solve it with products or treatments at verified salons, and rescan to see what changed. Salons, clinics and spas get real software for free, plus customers whose plans already recommend what they offer.

My role was systems designer and co-founder: I framed the problem, designed the product on both sides, the recommendation rules, the data and organisation model, the visual language and brand, and the go-to-market that is built into the product rather than bolted on after it.

Role
Systems designer, co-founder
Timeline
Platform built 14–20 Oct 2026
Market
Tri-City, India · phone-first
Status
Live in pre-launch · opens Christmas
Pages designed and shipped103

customer, salon portal, admin and public pages

84

data models, 25 enums

~290

API procedures across 29 routers

542

Tri-City businesses in the directory

500+

automated tests, including accessibility scans

01 · Problem and insight03

The usual answer is more. The honest answer is often less.

What people get today

A routine built to sell

  • A ten-step routineUpsell
  • A gold facial, every monthUpsell
  • Three serums, to be safeUpsell
  • Advice from whoever sells the productBias

Salons and counters are paid on what they sell, so the advice is rarely neutral. Most people leave with more products and still no clear idea what their skin needs.

What Betta Beaut gives

A plan, sorted into four lists

  • Necessary — what your skin actually needs now
  • Good to add — helpful, if it fits the budget
  • Do together — steps that work best as a pair
  • Avoid — often pushed, not needed, and why

Every item carries its reason. Salons and brands cannot pay to be recommended. The plan fits a real budget and a real amount of time each day.

The insight the whole product is built on: the valuable half of the advice is the half that tells you to stop.

02 · Systems thinking04

One system, two sides, a neutral core.

Every screen was designed against this map. The customer loop and the salon toolkit share one engine, one directory and one platform — so a salon's in-chair scan gives the same plan as the app, and a customer's plan is what brings salons their clients.

Customer side

Face scan

Consent, camera or upload. The photo is never stored.

Questions

Five short steps: skin, life, budget, time.

The plan

Necessary · Good to add · Do together · Avoid.

Rescan

Every four to six weeks; the plan updates.

Neutral core

Recommendation engine

Deterministic rules, a reason per item, budget and time aware, versioned and reproducible.

Directory · 542 businesses

Every Tri-City salon, clinic and spa from public data, on a map.

Neutrality rules

No paid ranking. Promotion always labelled. Upsells never recommended.

Salon side

Find & claim

An owner finds their page, then claims, fixes, removes or lists it.

Free toolkit

Client CRM, appointments, GST bills and invoices, follow-ups.

In-chair analyzer

A walk-in gets the same plan as the app, saved to their record.

Promotion

Shown to nearby plans that already need that service, always labelled.

Platform underneath

Identity

One person per phone or email, readable IDs, shared across both sides.

Organisations

Entity → branch → department, with eight scoped roles.

Messaging

WhatsApp, SMS and email through a single outbox.

Demo isolation

Sample organisations can never touch a real one.

Parts of this map are built and tested but deliberately switched off: bookings, four-hour product delivery and the salon supply marketplace all open together at launch. Until then the pages say so and the server refuses the orders, rather than letting a half-open flow look finished.

02 · Recommendation engine05

Rules you can read, not a black box.

The engine is deterministic: the same inputs give the same plan, every time. AI may reword a reason; it never chooses an item. That is what keeps the advice explainable to a customer and defensible to a salon.

  1. Adjust the readings

    Each adjustment carries its reason — humid air raises oil, under seven hours of sleep raises dark circles.

  2. Diagnose

    Up to three focus concerns above a threshold; strengths below one; graded mild, moderate or high.

  3. Fit the routine to the day

    Cleanser and sunscreen always. Treatment and moisturiser at ten minutes. Eye care only at twenty.

  4. Choose within budget

    Filtered for sensitivity, age, skin tone and past failures, then ranked by match, price and gentleness.

Safety overrides the ranking: severe, painful breakouts put “see a dermatologist” into Necessary and take the treatments out.

Four properties are enforced rather than promised. Ranking never uses margin or paid promotion. Upsell services are never recommended and strong acids never reach sensitive skin. Every item carries a reason, and AI may only reword it. Inputs are hashed with the engine version, so any plan a customer was once given can be rebuilt exactly.

02 · Data and organisation model06

A one-chair salon and a five-branch group on the same model.

The structure had to start simple — one user, one branch, free — and grow without a migration: legal entities for GST, branches with their own menus and prices, departments, and roles that never let anyone grant more than they hold.

The tree

Person

One per phone or email, readable ID, shared across both sides.

Organisation

Kind: real, sandbox, demo or demo visitor.

Legal entity

GSTIN, invoice series, bills of supply.

Branch

Its own menu, prices, stock and appointments.

Department

Teams inside a branch, with their own heads.

Eight roles

Owner · admin · branch manager · department head

Scoped to the organisation, an entity or a single branch.

Accountant · front desk · stylist · viewer

Only owners change owners, and nobody can grant a role above their own.

84 models, 11 domains

Identity · Organisations

People, sign-ins, entities, branches, approvals, audit.

Directory · Scan & plan

Listings, claims, verification, scans, plans, courses.

Commerce & supply · CRM

Orders, delivery, stock ledger, clients, packages, loyalty.

GST billing · Money

Invoice series, credit notes, subscriptions, commission, payouts.

Messages · Privacy

One outbox for every channel; consent per purpose, data requests.


I didn't know how to approach the market. Turning up on a salon's doorstep to pitch felt wrong. So the product had to let businesses find themselves.

My own note in the design handover · 15–20 Oct 2026

03 · Go-to-market, designed into the product08

Outbound sales, turned inbound.

The directory did more for sales than any pitch could. Every Tri-City business already has a page — so the first conversation starts with “your page is live”, not with a demo.

The usual way

Outbound

  • Build a list, cold-call, visit
  • Pitch software nobody asked for
  • Hire a sales team to scale it

Every conversation starts from zero, and the cost of starting one never falls.

What we designed

Inbound, from a page that already exists

  • Every business gets a public page from public data
  • Customers find it on the map; owners find it by search
  • The owner claims it, fixes it, or asks for it to be removed

Nothing changes on a page until the team verifies who is asking. A business that wants out is removed — the directory is a service to them, not leverage over them.

04 · Visual design evolution09

Nine checkpoints, every turn on the record.

Each step was shipped to the live site, judged against references in the browser, and either kept or turned around. The decisions and the reasons behind them went into the design handover, so nothing was decided twice.

  1. Aug 2025

    The first version

    A website-builder shop front: discounts, products, bookings. It sold things. It didn't answer anything.

  2. 14 Oct

    Deep violet, low cognitive load

    Twelve rules every page had to pass: one primary action, answer first, one question per step. Purple read as gender-neutral; soft lilac didn't.

  3. 15 Oct

    Frosted glass, 65 pages

    Glass on blurred colour, one typeface, a contrast table and a solid fallback. “Copy the newest iOS” turned out to mean the glass, not the layout.

  4. 17 Oct

    Liquid-glass tuning

    Clearer fill, saturated fields, a specular rim, a lighter veil. Still too opaque.

  5. 17 Oct

    v2, reference-led

    Photographic dusk scenes, smoky glass, ivory pills, numbered answers. The tiles and nav were still far from the references.

  6. 17 Oct

    v3, crisp dark glass

    One nav bar, bright jewel scenes, a 1px lit edge, a short tight shadow. The background read dull and the tiles read like tablets.

  7. 17 Oct

    v4, cool and gender-neutral

    Navy, cobalt, ocean, teal, emerald and one copper glow, with gold second lines. Magenta and coral had read as too feminine.

  8. 19 Oct

    Logo v1 and the brand book

    A sideways heart that reads as B, with a back layer that makes it BB. From a reference sketch, rebuilt as geometry.

  9. 20 Oct

    The wordmark

    Set solid in Jost Medium with the tt ligature, chosen from a grid of four geometric faces in three cases.

Five visual directions in three days was only survivable because every value lived in one file. The turnarounds were cheap because the system was cheap to change — not because the decisions were casual.

05 · Design system as code10

The rules aren't in a PDF. They fail the build.

A design-system lint rejects raw colours, raw palette classes, emoji used as icons, bold headings, and any button that isn't one of three kinds. It prints file and line, and exits non-zero.

White text over…On the sceneDefault glassCard on glassSolid fallback
Navy10.5213.3611.5614.34
Cobalt5.2411.609.9014.16
Sky4.8911.359.6614.12
Violet5.9511.9410.2214.19
Ocean5.2811.629.9014.16
Teal4.9611.459.7414.14
Emerald5.1711.589.8514.16
Copper5.6411.7910.0514.17

Every scene is modelled at full strength under the veil and the background's white lines — the brightest spot text can ever sit on. A unit test fails if any pair drops below its minimum, so changing a scene colour tells you before anyone sees it, not after.

This is the part I would argue hardest for on any project. A rule enforced by the system does not need anybody to remember it at four on a Friday afternoon.

07 · Trust and security as design11

Honesty isn't a tone of voice. It's an architecture.

A product whose whole promise is telling people what to skip only works if people believe it. So trust was designed at three layers: what the copy promises, what the server refuses, and what the database will never answer.

Before
Row-level security was applied table by table, by hand, as each one was added — which works exactly as long as nobody forgets.
What forced it
A gap shipped and went unreported. I found it myself and closed it the same day, but the real problem was that memory had been the control.
The decision
Every table gets row-level security on, a restrictive no-access policy and no grants to the public API roles, and a trigger locks each new table the moment it is created.
What it changed
An integration test now fails if any table is unlocked, run against the hosted database rather than a local copy. An audit script runs before and after every migration, and an outside-in check probes the API the way an attacker would.

The same principle runs through the copy and the data. “Coming soon” appears wherever something is coming soon. Every demo is labelled sample data. Guidance is marked as guidance, not medical advice. Face photos are read in memory and dropped, never stored. Visits are counted with no cookie and no identifier — which is why there is no consent banner to click.

08 · Outcomes and what's next12

Live, honest about what's open, and ready to meet the Tri-City.

Where it stands
  • Live at bettabeaut.com in pre-launch — salons can sign up and use the free toolkit today
  • 103 pages across customer, salon, admin and public surfaces
  • 542 directory pages waiting to be claimed, each labelled “not yet a partner”
  • 500+ automated tests, including browser and accessibility scans
  • Bookings, four-hour delivery and the supply marketplace built, tested, and switched off until launch
Still open
  • A face-analysis vendor to replace the test analyzer
  • Dermatologist review of the rule set before launch
  • Whether the salon demo stays open or needs a phone check first
  • Commission rate and subscription tiers
  • Our own consented photo shoot with Indian models, replacing stand-in photography

What I would tell the next systems designer on a project like this: design the go-to-market and the trust model with the same care as the screens. Here the directory did more for sales than any pitch could, and an honest “coming soon” did more for credibility than a launch date would have.

Know what your skin needs. Skip what it doesn't.

Betta Beaut · Chandigarh Tri-City · 2026

Product, systems, brand and go-to-market designed and built by me, Chandigarh Tri-City, 2026. Written from the project's own build record and design handover.

All case studiesBetta BeautWork with me

B-SIDEOff the record