Case studies
Community / regional development / events · 2023

Bilingual community app - jobs, housing, events, clubs in one place

Bilingual community app - jobs, housing, events, clubs in one place

Client
GOTO Sønderborg - ComeUnity app
Duration
6 months
Status
Shipped
Stack
Flutter 3.7+ · FastAPI + Postgres · In-app payment gateway · FCM + APNs push

What we solved

Sønderborg - Denmark’s 16th-largest commune - runs a regional initiative to keep young people connected to the city: locals who grew up there and moved away, plus students and new professionals relocating in. Content for that community used to live across event flyers, club sign-ups, and partner discount lists, with no single home. Members had three places to check and one place to actually go. Organisers had no way to list an event, gate it by age, sell a ticket, and push updates without a separate mailing list. ComeUnity - billed as the first Danish app bringing youth and student life onto one platform - is that one place.

The system at a glance

A trilingual (Danish / English / German) Flutter app for iOS + Android. Event calendar with paid and free ticketing, in-app club memberships (Food Club, Business Club, Baby Club, Mentor Program), push notifications across segmented channels, job and housing listings, internship placements, and a member-discount directory. Target audience: 18–35. Coverage: Sønderborg Municipality plus the broader Sønderjylland region.

What the user experiences

  • Open the app. Auto-selected language from device locale (Danish / English / German), switchable in settings.
  • Events: sort by date, promotion, distance, free / paid, or name.
  • Event detail: images, context, core members, price, buy ticket.
  • Entry Pass: paid tickets bought in the app, stored on-device.
  • Jobs + housing: study jobs, full-time opportunities, rooms and flats in the region.
  • Internships: structured placement listings for students.
  • Clubs: browse and join Food Club, Business Club, Baby Club, Mentor Program.
  • Member benefits: discounts at local shops, cafés, and businesses.
  • Pushes: today’s events, upcoming, new member content, job alerts - segmented so a user can mute any one channel.
  • Settings: language, profile, report a problem.

How we built the pieces

Three languages, not one-plus-translation

Danish, English, and German are first-class from day one, not bolted on with a translation layer. Event content supports simple body or full HTML so an organiser writing in Danish keeps the formatting intact.

Age gate - 18 to 35, server-side

Account creation takes a date of birth and gates content to the 18–35 window. The gate is server-side, not client-side: poking at the API out-of-range returns nothing.

Tickets - in-app payment, on-device pass

Paid tickets buy through the platform’s store billing or a Nordic-market gateway. The resulting pass is stored on-device and displays at the door.

Jobs + housing - different schemas, same surface

Jobs and housing are each their own content type on the backend with distinct schemas, but ship through a shared list/detail pattern in the app. Fewer custom screens; faster iteration.

Pushes - segmented, not a firehose

Four independently muteable push channels: today’s events, upcoming events, new content, job alerts. Users who want reminders for tonight only are not forced into weekly newsletters - which is how opt-out rates stay sane.

The plumbing underneath the calendar

Community apps fail when they ship the calendar and skip the boring infrastructure. ComeUnity does the unglamorous plumbing well: trilingual content pipeline, age-gated API, paid ticketing, segmented push, and jobs + housing alongside events. That is why a regional initiative gets one app members open, instead of three channels no one checks.

Results

  • iOS + Android live from one Flutter codebase with three languages.
  • Paid and free ticketing working from listing to door-scan.
  • Age-gated access enforced at the API.
  • Events, clubs, jobs, housing, internships, and mentor program all in the same product.
  • Live on App Store (id6476504922) and Google Play (dk.gotosonderborg.app).

What an engineering team should take from this

If you are shipping a regional community app in a non-English-primary market:

  1. Plan for multilingual from day one, including HTML event bodies - retrofitting translation later is painful.
  2. Age and role gates belong on the server, not in the client.
  3. Segment push channels so users can mute part of the firehose without muting all of it - opt-out rates drop sharply.

Tech stack

  • Mobile: Flutter (iOS + Android, trilingual UI)
  • Backend: FastAPI + Postgres (inferred default)
  • Payments: in-app store billing + Nordic-market gateway
  • Push: FCM + APNs, four segmented channels
  • Content: CMS with HTML body support, trilingual strings

Screens

GOTO Sønderborg / ComeUnity - three iPhones showing event calendar, event detail, and mentor profile

Reference architecture

The stack, one-pass.

Named pieces, how they connect, and why each one earned its spot.

  • 01Flutter 3.7+

    iOS + Android with shared bilingual/trilingual UI from one codebase (era-appropriate for 2023)

  • 02FastAPI + Postgres

    typed endpoints for events, jobs, housing, clubs, members, tickets

  • 03In-app payment gateway

    paid tickets and memberships purchased inside the app

  • 04FCM + APNs push

    today's events, upcoming events, new member content, job alerts

  • 05Device locale detection

    auto-select Danish, English, or German from phone settings

  • 06CMS with HTML body support

    organisers publish rich event and opportunity pages without a release

Full stack

Every piece, named.

  • Flutter 3.7+
  • FastAPI + Postgres
  • In-app payment gateway
  • FCM + APNs push
  • Device locale detection
  • CMS with HTML body support
The team on the call

Named engineers, not a pool.

You speak to the person who’ll review the architecture. No account-manager layer. No offshore switcheroo.

Founder & Lead Engineer

Sameer Donga

Shipping Flutter, FastAPI, and AI systems since 2019. Reviews the architecture on every engagement.

Start a similar build

You have the reference. Now the project.

Tell us the shape of your version. We come back with a written architecture and a fixed quote.