Kinship

Dashoboard showing cluster
Login page for new user and existing user
Our dashboard analyze the information provided by user and match with existing users
crisis mode
Flood simulation
Application working in offline mode when there is no connection
AI chatbot

Inspiration

It was 3am during the 2022 floods in Lismore, NSW. A woman in her 70s was trapped on her roof, water rising. Her phone was dying. She didn't know her neighbours' names. Emergency services were overwhelmed. She survived but only because a stranger in a tinnie happened to pass by. That story stayed with us. We kept asking ourselves why do we only meet our neighbours when something goes wrong? Why does community only activate in crisis, when it's already too late to organise? We have apps that connect us with restaurants, rideshares, and strangers across the world. But when the power goes out and the roads flood, we are completely alone with the people who live 50 metres away from us. The reality is that in any major emergency like flood, bushfire, earthquake or blackout the first 24 to 72 hours are handled almost entirely by ordinary people. Not government agencies. Not emergency services. Neighbours. And yet we have built almost no infrastructure to help those neighbours find each other, understand each other's needs, or coordinate before the disaster arrives. We wanted to change that. We wanted to build something that quietly works in the background during peaceful times, so that when crisis hits, your community is already ready. That's Kinship. Find your people before you need them.

What it does

Kinship is an AI-powered neighbourhood emergency resilience platform. It connects residents within a suburb, matches them based on complementary skills and needs, and keeps them connected even when the internet goes down. Onboarding & Capability Mapping When you join, you tell Kinship what you can offer in an emergency like a car, first aid training, a generator, spare room, language skills and what you might need help with. Our AI parses your plain-language input into structured capability and need tags. We never store your exact address. Coordinates are intentionally fuzzed for privacy. AI-Powered Cluster Generation AI groups 4–6 nearby residents into a Resilience Cluster, not just by proximity, but by complementary skills. Someone who needs transport is matched with someone who has a vehicle. Someone who only speaks Vietnamese is matched with a bilingual neighbour. Each cluster gets a Resilience Score and a Gap Analysis showing what's missing. Crisis Mode When disaster strikes, cluster members can check in or updates status like Safe, Need Help, Helping Others, or Evacuated. The map updates in real time. Phone numbers, hidden during normal times, become visible to cluster members only when crisis mode is active. Because in an emergency, people need to actually reach each other. Offline & P2P Resilience When the internet goes down which it always does in the worst disasters, Kinship doesn't stop working. It degrades gracefully through three modes: Online → P2P mesh network → Offline cached data. Cluster member information, check-ins, and contact details are cached locally so they're available even without connectivity. QR codes enable peer discovery when there's no cellular signal. AI Chatbot Assistant A context-aware chatbot adapts its tone depending on the situation which is practical during onboarding, calm and warm during mental health moments, urgent during crisis. It detects language automatically and responds in the user's preferred language.

How we built it

Frontend: Next.js 14, TypeScript, Tailwind CSS, Zustand for state, Dexie (IndexedDB) for offline persistence, Leaflet for maps, Simple-peer for WebRTC P2P. Backend: Python FastAPI, with intelligent LLM routing ( Groq (llama-3.1-8b-instant)) in production for fast inference, local Ollama in development to avoid API costs during iteration. AI: Claude API for cluster generation , we send all suburb residents' profiles and let Claude reason about who should be grouped together based on proximity, complementary skills, language diversity, and vulnerability. If Claude is unavailable, a distance-based fallback clustering algorithm kicks in automatically. Database: Supabase PostgreSQL, with a full offline mirror in IndexedDB so the app keeps working when connectivity fails. Privacy: We deliberately fuzz GPS coordinates before storing them. Nobody's exact address is ever saved. Phone numbers are stored but hidden behind a crisis-mode gate which is invisible in normal use, visible only when lives may depend on it. The hardest engineering challenge was the three-tier offline degradation system. We built Dexie sync logic that writes every cluster fetch to local IndexedDB, then reads from that cache when the connectivity mode switches to offline or P2P. The app genuinely works without internet and that matters, because the scenarios where you most need it are exactly the scenarios where infrastructure fails.

Challenges we ran into

Location accuracy without surveillance. We wanted the map to be genuinely useful and members close enough to actually help each other but we didn't want to build a surveillance tool. The balance between fuzzed coordinates (for privacy) and accurate proximity matching (for clustering) required careful calibration. We add controlled random noise to coordinates before storage so two neighbours on the same street appear nearby but not exactly locatable. Suburb inconsistency breaking cluster formation. Our cluster algorithm queries the database by suburb name. We discovered that "Moorabbin", "moorabbin", and "Moorabbin " (with a trailing space) are all different strings in a case-sensitive database. Four real users we registered for testing never got clustered together because of this silent data mismatch. Switching from .eq() to .ilike() with normalisation fixed it but finding it required reading raw Supabase rows. Crisis state persistence across page navigation. Phone number visibility was gated behind an isCrisis flag but we'd stored it in local React component state, which resets on every page mount. A user who activated crisis mode and navigated back to the dashboard would see contact details disappear, defeating the point entirely. The fix was moving to the Zustand store, which persists across navigations. Making offline feel real, not degraded. It's easy to slap an "offline mode" banner on a broken screen. It's much harder to make offline feel intentional and useful. We pre-cache cluster members, capabilities, needs, and profiles to IndexedDB on every successful online fetch, so the dashboard loads fully even with no connection.

Accomplishments that we're proud of

We're proud that Kinship actually works end to end, with real users, in real scenarios. We're proud of the offline resilience stack. Building a system that gracefully degrades through three connectivity tiers, maintains useful functionality at every level, and recovers automatically when connectivity returns that's genuinely hard to do well. We're proud of the privacy choices we made when nobody asked us to. We could have stored exact coordinates. We could have shown phone numbers all the time. We chose not to. We think that matters, especially for a platform used by vulnerable people elderly residents, people with disabilities, non-English speakers who may not fully understand what data they're sharing. We're proud of the crisis phone number gate. It's a small feature of four lines of code but the thinking behind it took us a long time. Phone numbers should be private during normal times. But in a crisis, a neighbour's phone number could be the difference between life and death. The gate exists because both of those things are true simultaneously. And honestly, we're proud that we got clusters to actually form. Debugging the suburb string inconsistency at 2am, running SQL queries directly against Supabase, realising that "Moorabbin " with a trailing space was a completely different suburb from "Moorabbin" and fixing it felt like a real win.

What we learned

Build for failure first. We kept saying "we'll add offline support later." Later never comes. By the time we had a working online app, the thought of retrofitting offline support felt enormous. We learned that if offline resilience is a core requirement and for an emergency app, it absolutely is and it has to be designed in from the beginning, not bolted on at the end. Real data breaks everything. Our test accounts were clean. Same capitalisation, no trailing spaces, correct suburbs. When real users started signing up, the data was immediately messy. Lessons: normalise at write time, query with tolerance, and always test with data entered by actual humans who don't read your documentation. Emotion drives better product decisions. When you're building something that might help someone's elderly Vietnamese-speaking grandmother get evacuated safely, you make different product decisions than when you're building a CRUD app. The privacy-first choices, the multilingual chatbot, the crisis phone gate all of those came from genuinely thinking about the people who would use this when it mattered most. State persistence is underrated. We had three separate bugs caused by the same root mistake: assuming that component-local state would survive a page navigation. Zustand for cross-page state. Dexie for cross-session state. IndexedDB for offline state. Getting this architecture right was one of our most valuable technical lessons.

What's next for Kinship

Real P2P mesh networking. Our current P2P layer simulates WebRTC connections. Building a real mesh network where phones relay messages to each other without any central server is technically achievable and would make Kinship genuinely useful in large-scale infrastructure failures. Push notifications for crisis alerts. When a crisis event is created for your postcode, your cluster should be notified immediately even if the app is closed. Community resource registry. Beyond individual capabilities, clusters could register shared resources — a community generator, a water tank, a first aid kit. Visible on the map, managed collectively. Formal onboarding with local councils. The long-term vision is for Kinship clusters to be recognised by emergency services as part of the official community response infrastructure. That means building trust, data governance, and integration pathways with agencies like the SES and Red Cross. More languages. Our chatbot detects and responds in multiple languages, but the onboarding UI is English-only. For the communities most likely to be vulnerable in emergencies like recent migrants, non-English speakers , that's a barrier we want to remove.