Case study · Community app

↳ Product · UX · UI · Design system

One place instead of
five separate chats.

Communities and associations used to hold everything together with WhatsApp groups, a spreadsheet and a noticeboard by the door. We designed and built an app that replaces all of it with one place — on the web, on iPhone and on Android.

Product · UX · UIRole

Web · iOS · AndroidPlatforms

Next.js · Expo · SupabaseStack

In productionStill iterating

App home screen showing items to handle and upcoming events — **Home.** Deliberately not a news feed but a task list — "To handle" at the top shows exactly what the council has to resolve today.

↳ 01 — Context

A community is not a company — but it needs the same overview.

The Zvon community has dozens of members, dozens of volunteer duties (musicians, tech, cleaning), small groups, recurring and one-off events — and alongside all that it runs courses and counselling for people who are not part of the community at all. Previously this was held together by half-working tools: WhatsApp for arranging duties, a spreadsheet for course attendee lists, paper by the door for signing up to a work day.

The brief was never "let’s build an app". It was: design two separate but connected worlds — community members and external programme participants — so they never get in each other’s way, yet can be linked where it makes sense (a member running a course for outsiders, for example).

2independent user worlds — members and programme participants

3platforms at once — web, iOS, Android

1chat system for events, duties, groups and courses

0extra apps to install

↳ 02 — Solution

Three decisions that carry the whole app

Every module has to answer a question the community actually asks — not mirror the shape of the database.

01Calendar

RSVP + event crew

An event carries not only a date, but who is attending and who is running it that day (sound engineer, host). Signing up for a duty sets the RSVP automatically — no need to do it twice.

02Directory

Members with per-field visibility

Phone, address, birthday — each member decides what the rest of the community can see. The app enforces this at the level of a single field, not the whole profile.

03Chat

One system, four contexts

Events, duties, small groups and courses each get their own channel with the right access — without the app needing four different chat screens.

Event calendar with a list and a mini calendar — **Calendar.** A month list on the left, an orientation mini-calendar with activity dots on the right.

Event detail with Going/Maybe/Not going and Overview, Crew, Documents tabs — **Event detail.** RSVP, crew and documents under one roof; this event is also open to external participants.

List of community members with skills and group membership — **Directory.** Search by name or by skill, with a badge for group and duty membership.

.../members/martin

Member profile. Only the fields that member chose to reveal; the app never reads personal data directly, only through a view that enforces the rule.

List of chat channels ordered by latest activity — **Chats.** One channel list across events, duties, groups and programmes, ordered by activity.

List of volunteer duties with a Request access button — **Duties.** Joining a volunteer duty goes through a request and an approval, never automatically.

↳ 03 — Design system

"Ohnisko UI Kit"

The app grew screen by screen before it had a unified look — colours, spacing and type drifted apart across web, mobile and the portal. We built a shared component library across all three apps: colour tokens, a type scale, consistent spacing and one icon set instead of emoji used as icons.

The focus was on making dark mode genuinely work — not just on the bottom bar, but across the whole screen content — and on keeping the app readable at increased browser font size, which is why the entire type scale is in rem, not fixed pixels.

brand-600bgpaperinkmutedline

List of small groups — Small groups — the same card pattern as Duties, components shared across the app.

Bilingual community pages — Statutes, Mission, Membership fees — Community — bilingual content (SK/EN) with its own attachments per language.

App login screen — Login — passwordless, via a link or a six-digit code by email.

App home screen in dark mode — **Dark mode.** The same tokens with an inverted value scale — checked on real screens, not just on components in isolation.

↳ 04 — For the council

Numbers the council previously had nowhere to get

The admin area for the community council got its own reporting section — event attendance, course capacity, activity across duties, membership growth and an estimate of programme income, each with a CSV export. Plus a free-form natural-language question that picks from pre-built, community-data-aware functions — the app never lets AI near free-form SQL.

Programme administration with publishing state and pending requests — **Programmes.** Courses and counselling by month, publishing state in one click.

Reports page with a free-question field and programme capacity overviews — **Reports.** Seven prepared overviews plus a prompt for a free question about community data.

↳ 05 — Mobile

Same decisions, less room

Community members live in the native iOS/Android app, not in the mobile web. The same information model as on the web — "to handle" at the top, calendar below — reworked for a thumb rather than a cursor.

Mobile home screen of the app — Home (iOS)

↳ 06 — Results

Where the app stands today

Done and in production:

Multi-tenant app with data isolation at the database level — ready for a second and third community
A unified design system across web, mobile and the portal, including dark mode that genuinely works
A reporting set for the council with CSV export and prompt-based querying
Background push and email notifications, including web push for external participants without the app
Signing up for a duty also handles the event RSVP — one action instead of two

Product and design in one person — from the first wireframe to an app the community actually clicks through today.

More work
Back to Case studiesView all →

One place instead offive separate chats.