Case study
Randalo
Your people. Your city. Your night.
Randalo is an events and community app for German-speaking countries. I started it with two co-founders and have been building the platform behind it ever since: architecture, backend, cloud and web front ends.
- Role
- Co-founder & managing director
- Team
- with Nic Markfort and Jannik Nohn
- Since
- January 2026
- Platforms
- iOS, Android, web
- Status
- Beta, live on the App Store and Google Play
01 Background
One night, one app.
Doing something together usually means jumping between tools: you find events on social media, plan in a messenger, settle costs in yet another app, and the photos end up scattered across everyone’s phones. Meanwhile, much of what happens in your own city goes unnoticed.
Randalo brings it into one app: discover, plan, split costs, play and remember. For groups of friends just as much as for clubs, crews and organisers who appear as an Orga.
What the app does
Discover
Find events nearby on the map, in the feed and in the calendar, and subscribe to places to get a push notification for new events.
Organise
Create events from an occasion, repeat them as a series, hand out roles and polls, and invite by link or QR code.
Orgas
Crews and clubs found an Orga with members, roles, their own calendar and a shared chat.
Kasse
Track expenses, see balances and settle up in a few payments. The money itself never flows through Randalo.
Games & tournaments
Party games, a photo game and tournaments with schedule, standings and live scores, on iPhone even on the lock screen.
Gallery
Every photo of the night in one place. Guests without the app upload through a photo link.
02 My role
The platform, end to end.
We are three founders and managing directors. I own the technical platform and wrote about half of the 2,400+ commits in the monorepo, most of the backend and infrastructure among them.
01
Architecture & backend
Ten domain services on .NET 10 and gRPC, a REST gateway with FastEndpoints and realtime over SignalR.
02
Cloud & operations
The whole Azure environment as code in Bicep, deployments through GitHub Actions and telemetry with OpenTelemetry.
03
Web front ends
Organiser portal in Next.js, tournament board in Vue, admin console in TanStack Start and the randalo.events website in Astro.
04
Automation
AI-assisted event import from links, a media pipeline without manual steps, and an orchestrator that spins up short-lived servers for tests and tears them down again.
05
App & repository
Work on the Flutter app and bringing app, backend, website and infrastructure together in one monorepo.
03 Architecture
Under the hood.
The app and three web front ends talk to a .NET 10 backend made of domain services. Public clients only go through the public API; internal tools like the organiser portal and admin console call the services server-side over gRPC. Everything runs in Azure Container Apps in a European region.
Clear boundaries
Each service owns its schema in a shared Azure SQL database and talks to others only over gRPC or messages.
Async where it fits
Changes such as new memberships spread through MassTransit and Azure Service Bus, backed by an outbox.
Local like production
.NET Aspire starts every service along with database, message bus and emulators in a single command.
Infrastructure as code
About 100 Bicep files describe the Azure environment, from database roles to domains and certificates.
04 Media pipeline
From upload to finished video.
Photos and videos don’t just land in storage: every file is uploaded in chunks, verified by checksum, scanned for viruses and then automatically turned into the right image sizes or HLS video streams. This is exactly the kind of process I build for businesses too: robust, free of manual work and designed to recover from failures on its own.
Idempotent
A strictly increasing workflow revision makes sure redelivered messages can’t mix anything up.
Scales to zero
The workers run as Container Apps jobs that only start when there is work in the queue.
Transparent
The app shows progress live over SignalR: requested, virus scan, processing, done.
05 How we work
How we build.
- commits since December 2025
- 2,400+
- .NET projects
- 77
- test files in the app
- 1,400+
- architecture decisions (ADRs)
- 16
Decisions on record
We record architecture decisions as ADRs, for example that payments never run through the app or that a series creates real individual events.
Tests on throwaway servers
Integration tests run against the full Aspire stack on short-lived Hetzner VMs that our own orchestrator starts and cleans up.
Contracts in check
CI regenerates the generated gRPC client code. If it drifts from the .proto files, the build fails.
AI on the team
We build with AI agents like Claude Code that know the repository’s conventions through project-specific rules and skills.
06 Timeline
From idea to the stores.
Dec 2025
Kick-off
The first commits for Randalo.
Jan 2026
The backend begins
I set up the .NET backend that grew into today’s service platform.
May 2026
Restart in Flutter
The app moves from FlutterFlow to its own Flutter code.
Jun – Sep 2026
Beta 1.0
First beta builds with events, map, chats, gallery, tournaments and party games.
Aug 2026
Randalo UG
The three of us become managing directors of Randalo UG (haftungsbeschränkt).
Sep 2026
Version 1.1
App Store submission, Sign in with Apple and a minimum age of 18.
Oct 2026
Versions 1.2 and 1.3
New event page, invites by QR code, photo game, Orgas with Kasse, series and Live Activities on iPhone.
Oct 2026
One monorepo
App, backend, website and infrastructure now live in a single repository.
Planning something similar?
Whether it’s an app, a platform or automating a process: I’ll help you build it properly.