Back to projects
Community SaaSiOS + AndroidSolo · end-to-end
Project

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.

RoleDesigner + developer
Timeline3 weeks
PlatformiOS + Android
StatusIn testing
01 — 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–300Flats per society, coordinated manually
4 → 0Tools in use, with zero sync between them
UnpaidVolunteer admins carrying it every week
02 — 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.

03 — 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.

04 — 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.
05 — Summary, at a glance

The whole project, in four moves.

Situation

A 100–300 flat apartment society ran everything by hand — announcements, records, event sign-ups, and approvals split across WhatsApp, paper registers, Google Forms, and Excel, with no shared source of truth.

Task

Give residents, admins, and coordinators a way to know their own status — registered, approved, checked in — without messaging a person and waiting for a reply.

Action

Reviewed the manual process, interviewed the people running it, and mapped both journeys. Designed and built a two-sided app solo — self-service registration, status shown before entry, one-tap approvals, on-device QR check-in — and shipped it to iOS and Android.

Result

Running a 200-flat society now feels like running 20 — one shared source of truth, zero status interruptions by design. Hard numbers (task completion, time saved) are being validated in usability testing now.

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 — 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.

10 — 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.
11 — 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.

12 — The shift

What changes, from the old way to the new.

200→20The effort to run a 200-flat society now feels like running 20.
Before — the manual wayAfter — 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.

13 — Selected screens

The app.

Key moments from the resident and admin experience — final screen captures to be added.

Resident
Event List
to be added
Registration
Wizard
to be added
QR Ticket
Screen
to be added
14 — 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.

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.