Community SaaSiOS + AndroidSolo · end-to-end
Case study

Kinship

Replacing 300 WhatsApp messages a week with one app a community actually trusts.

Objective — give admins and residents a single source of truth, so coordination runs itself instead of running through a person.

Role
Designer + Dev
Timeline
3 weeks
Platform
iOS + Android
Status
In testing
9:41▲ ● ▮
Diwali Meetup · Block C
You're registered
Confirmed · 2 guests
Slot6:30 PM
Availability12 spots left
Show QR at entry
Scroll
01 — At a glance

The whole project, in four beats.

The short version before the story — situation, task, action, result.

S
Situation
Admins ran hundreds of flats manually through WhatsApp, Excel, and paper. Residents had no structured way to register or track approvals.
T
Task
Design and build a full-stack two-sided app — approvals, events, QR check-in — on iOS and Android.
A
Action
Documented problems, interviewed co-hosts, mapped journeys, built wireframes and a design system, then developed it solo.
R
Result
Coordination that once needed a message, call, or visit now happens independently — transparency for residents, scale for admins.
02 — Overview

A whole community, run by hand across four disconnected tools.

A society of 100–300 flats coordinated announcements, resident records, event sign-ups, and approvals across WhatsApp, paper registers, Google Forms, and Excel — with no shared source of truth between admins and residents.

100–300
Flats per society, coordinated manually
4 → 0
Tools in use, with zero sync between them
Unpaid
Volunteer admins carrying it every week
03 — Background & trigger

What was happening before this existed.

Before the project

Coordination lived entirely across disconnected tools — chat threads, spreadsheets, and paper — with no shared source of truth between admins and residents.

Why it mattered

The manual process didn't just slow things down — it created unpaid, invisible labor for admins and constant uncertainty for residents who had no way to confirm their own status without asking a person.

04 — Who feels it

Three people feel it, in three different ways.

The admin
An unpaid volunteer absorbing hours of repetitive approvals and record-keeping that never ends.
The resident
No way to confirm their own status — every question means finding and messaging a person.
The coordinator
Interrupted mid-event by people asking when their slot is, unable to enjoy the event they run.
05 — The problem, and the bet

Everything ran by hand — so I replaced the person with a system.

Problem

No shared source of truth, and no way to self-serve.

Admins lost hours every week to repetitive approvals and record-keeping. Residents couldn't answer "am I on the list?" without messaging a person and waiting. Coordinators were interrupted mid-event, unable to enjoy the event they ran.

Solution

One structured, two-sided app.

  • Self-service registration — login by block, flat & PIN, no accounts.
  • Availability shown as a badge before entry, not after submit.
  • One-tap admin approvals, one screen per flat.
  • On-device QR check-in — no email, no PDF, no third party.
  • Status residents can see themselves, anytime.
06 — Users & context

Who this was built for, and where.

Target users
  • Residents of apartment societies — no defined age limit, any community context.
  • Society administrators — typically unpaid volunteers managing the operation.
  • Event coordinators running activities on the ground.
Environment

Any residential community or housing society, accessed primarily on smartphones (iOS and Android), in the moments of everyday community life — moving in, checking event details, or showing up to an event.

07 — Design process

From mess to shipped app, in five moves.

Step 01
Review the current mess
Pulled the history of events run by hand, logged every point the process broke, and separated real problems from assumed ones.
Step 02
Interview the people running it
Sat with the co-hosts who had actually run events and captured their friction in their own words — surfacing the status-and-trust insight.
Step 03
Map the journeys
Drew the resident and admin paths end-to-end, marking hesitation, re-entry, and drop-off, then prioritised what to fix first.
Step 04
Design the two sides
Low-fidelity wireframes, a reusable design system, and the key calls: flat + PIN login, availability before entry, on-device QR.
Step 05
Build and ship
Developed the full-stack app solo, shipped to iOS and Android, and moved into the current testing phase.
08 — Research methods

What we did, and what each told us.

A mix of discovery, synthesis, and evaluative methods — each aimed at a different question, each with outcomes that shaped the build.

1 · User interviews Qualitative · discovery
Who — co-hosts who had run past eventsFormat — 1:1, semi-structuredGoal — friction in their own words
What we did
Sat with the volunteers who had run events across WhatsApp, Forms, and Excel and walked each of them through a real event end-to-end — asking them to mark every moment that cost time or created confusion, captured in their own language rather than led.
Outcomes
  • The recurring pain wasn't speed — it was that no one could see their own status without asking a person.
  • Coordinators were interrupted mid-event, unable to enjoy the event they were running.
  • Closure mattered more than features — people wanted proof something had actually happened.
2 · Retrospective review Discovery · audit
Source — history of events run by handMethod — trace each tool's break pointsOutput — a failure inventory
What we did
Reviewed the actual record of events coordinated manually, tracing exactly where WhatsApp, Google Forms, and Excel broke down in practice — and deliberately separating the problems that were real from the ones that were merely assumed.
Outcomes — the five failure points
  • No visibility into availability — residents couldn't tell if spots were open before registering.
  • No way to separate pre-approved flats from ones needing manual review.
  • Repeated data entry — group registrations re-typed every member, every time.
  • No confirmation after registering — nothing to point back to.
  • Details buried in WhatsApp chat history.
3 · Journey mapping Synthesis
Scope — resident + admin paths, end-to-endLens — hesitation, re-entry, drop-off
What we did
Drew both the resident and admin paths end-to-end and marked every point where people hesitated, re-entered data, or dropped off — then prioritised which moments were worth fixing first.
Outcomes — design moves it pointed to
  • Move spot availability before entry, not after submit.
  • Give every registration a durable, visible confirmation (the QR ticket).
  • Collapse admin approvals to one screen, one tap per flat.
4 · Usability testing Evaluative · in progress
Design — task-based, old flow vs. appSample — to be definedStatus — running now
What we did
Task-based sessions comparing the old manual coordination flow against the app, timing the core tasks for both residents and admins as the app moves through its testing phase.
Outcomes — to be validated
  • Task-completion rate on the core flows — register, approve, check-in.
  • Time saved per admin, per event.
  • Direct resident and admin quotes to evidence the qualitative impact.
09 — Behavior loop

What people actually did — and the shift the product makes.

Repeated behavior observed

Residents would repeatedly approach event organizers in person to ask when their slot was or whether they were confirmed — interrupting the organizer's ability to actually run the event.

The workaround it replaced

Residents had to physically find and sit with organizers to get an answer, which meant organizers often couldn't participate in or enjoy the events they were running.

The shift this product makes

Status — registered, confirmed, checked in — becomes something a resident checks on their own screen, not something they ask another person for. That single change is what gives coordinators their event back.

10 — The insight

The real problem wasn't that things were slow. It was that no one could see their own status without asking another human.

11 — User flows

How it actually works — and what got simplified.

Resident journey

Register flat → get approved → discover events → register → attend with a QR ticket.

Admin journey

Configure the society → approve residents → create and schedule events → run them live, scanning tickets.

What I simplified
  • Login by block + flat + PIN — no account creation.
  • Registration cut to two steps, family members pre-filled.
  • Availability shown as a badge before entry, not a post-submit error.
  • QR tickets generated on-device — no email, no PDF, no third party.
  • Admin approvals collapsed to one screen, one tap per flat.
12 — Experience goals & the bet

Replace the human — but hand back the certainty.

The interface had to create confidence and closure: every action — registering, approving, checking in — ends in an immediate, visible confirmation, so no one has to wonder whether something actually happened. That principle is why status became something a resident checks on their own screen, not something they ask a person for.

13 — Explore the app

See the app in action.

Open the interactive walkthrough of the resident and admin experience — registration, approvals, and QR check-in — in a new tab.

kinship · interactive walkthrough
Open the Kinship walkthrough
A guided tour across the resident and admin sides — the landing screen, event registration, approvals, and on-device QR check-in.
Open in a new tab
14 — The shift

What changes, from the old way to the new.

200→20
The effort to run a 200-flat society now feels like running 20.
Before — the manual way
After — with Kinship
Admins spent hours every week on repetitive approvals and record-keeping.
Registration, approval, and check-in happen on their own.
Residents had to message a person and wait to learn their status.
Residents check their own status anytime, on their own screen.
Coordinators were interrupted mid-event by people asking about slots.
Coordinators get their event back — zero status interruptions by design.
Event details were buried in WhatsApp chat history.
One shared source of truth everyone can see.
Hard metrics — task completion, time saved — are being validated in usability testing now.
15 — Learnings

What I'd carry forward.

What I learned

Removing a human from a workflow only builds trust if the system replaces them with something equally reassuring — a badge, a confirmation, a status people can check themselves.

What I'd improve

Formal usability testing with a defined sample size, to move the impact metrics from "to be validated" to measured.

Coordination that once needed a message now happens on its own.

Kinship · Community management, reimagined
Have an idea?

Let's bring it to life together.

From a rough sketch on a napkin to a shipped product — share what you're thinking and let's shape it into something real.