A native app that gives a residential building one place to live: tenants, house committee and service providers, each with their own dashboard and permission set.
Role
Product · UX/UI · Full-stack
Type
iOS · Android
Stack
React Native · Expo · Supabase
Scope
118 screens · 3 user types
What it is
A residential building generates a surprising amount of coordination: monthly dues, faults, votes, documents, shared amenities and a maintenance schedule. Almost all of it happens in a WhatsApp group where nothing is recorded and nobody is accountable.
Doodi gives the building a single system with three user types and granular permissions - a tenant sees their own dues and can report a fault; a committee member manages residents, finances and suppliers; a service provider manages quotes, contracts and calls.
The problem
Building life lives in WhatsApp - Faults, payments and votes scattered across group chats
No shared record - Nobody can say who paid, who voted, what was decided
The committee works blind - No picture of the building fund or outstanding debts
Suppliers are informal - Quotes and contracts held in someone's phone
The solution
A dashboard per role - Tenant, committee member, service provider
Payments and faults tracked - With history and status
Votes and documents - Community decisions recorded
Amenities and maintenance - Bookings and a maintenance schedule
Brand
The logo is the name drawn as a friendly face: the two o's are blue eyes and a small orange smile sits under them, so a building app that handles money and faults still feels like a neighbour. The letters are drawn rather than typed - heavy, round and geometric - and the app uses only the logo's two colours and their tints.
Symbol and logotype, in black, in white and in colour. The app icon puts the wordmark on Doodi Blue.
Doodi Blue#2B30E1 Primary, the eyes
Doodi Orange#FF6700 Accent, the smile
Blue dark#1F24B8 Pressed states
Ink#171717 Text
Ground#FAFAFA Screens
Two colours and nothing else, so a tenant, the committee and a technician all know at once which app they are in.
DoodiDrawn wordmarkCustom letterforms, as vector paths
Aa 123SF ProThe interface, iOS
אבגSystem HebrewHebrew, right to left
The phone's own system type, so 118 native screens read like they belong to the phone.
The app on three phones - tenant, house committee and service provider, real screens
In the lobby, on a tenant's phoneThe committee's notice by the liftA service provider's vanA decal on the building's entrance
How it's built
App
React Native
Expo · native iOS and Android Hebrew RTL
Data
Supabase
PostgreSQL · row-level security realtime
Auth
Phone + password
Role- and building-scoped access
Scale
118 screens
Tenant · committee · provider with assistant delegation
The screens
One number first
Every dashboard leads with the single number that matters to its role, on a blue card that carries the logo's eyes and smile as a faint watermark. A resident sees what they owe; a committee member sees this month's collection against its target; a service provider sees the next job. Below it, only what is waiting for you.
A fault, from report to fixed
Reporting is a category grid and a colour-coded urgency picker, with errors shown under the field rather than in a pop-up. Each fault then has a three-step tracker - opened, in progress, fixed - a details card, the assigned provider one tap away, and a sticky bar to comment or update the status.
Paying and deciding
Payments show the balance, then the open charges; paying is a confirm sheet with the total and the card, never a new page. Votes show the question, a single choice, and live results bars once you've voted.
The building's paperwork
Messages are an inbox grouped by day with unread markers; documents are searchable with category chips and file-type icons; service providers carry their rating and a call button. Every list has real loading, empty and error states.
Design decisions
01
Three roles, one system - A tenant, a committee member and a supplier need different products. They share a design system and a data model, not a screen.
02
Onboarding is the product - Joining a building by code and setting up a committee are first-run flows, not settings buried in a menu.
03
Native, not a wrapper - Faults get photographed, payments happen on the phone, notices need push. That argued for React Native over a web wrapper.
04
Hebrew RTL throughout - Layout, navigation and typography built right-to-left from the start.
05
Money demands a record - Every payment and every vote leaves a trail. In a shared building, an unrecorded decision is a dispute waiting to happen.
