Technaut Parking — Offline-First Parking MS
Offline-First · Operations
All work
BMMarketplaceFull-Stack PlatformsCase study
Baaja — Music & Events Platform
Connects artists, venues and fans around event discovery and booking on one platform.
Music and events platform connecting artists, venues and fans through event discovery, profiles and booking — React web with a Kotlin Android app, published on the App Store.
Live siteSource private
- Industry
- Music & Events
- Role
- Full-Stack Engineer
- Type
- Mobile App
- Year
- 2024
- Status
- Delivered
Web + Android
Surfaces
Artists · Venues · Fans
Sides
App Store
Distribution
Overview
Baaja is a music and events platform with a React-based website and a native Kotlin Android app, connecting artists, venues and music enthusiasts through event discovery, booking and community features over a shared backend.
The problem
Artists, venues and audiences had no shared place to find each other. Bookings happened over phone calls and social DMs, venues had no way to surface open dates, and fans had no reliable listing of who was playing where.
The solution
Built a three-sided platform: a React + TypeScript web app for discovery and venue management, a native Kotlin Android app for on-the-go browsing and booking, and a shared backend holding artist profiles, venue listings, events and reviews.
Technical stack
Frontend
- React
- TypeScript
- Tailwind CSS
- Vite
Backend
- Kotlin
Also used
- Android
System architecture
- 1
React + TypeScript web client built on Vite with Tailwind CSS, covering event discovery, artist profiles and venue-side management
- 2
Native Kotlin Android app consuming the same backend contract, published through the App Store listing alongside the web experience
- 3
Shared backend owning the artist / venue / event domain, the booking workflow and user reviews
Engineering challenges
Challenge
Three audiences — artists, venues and fans — needed different views of the same event data.
How I solved it
Modelled events once and derived each role's view from it, so a venue publishing an open date, an artist accepting it and a fan discovering the show all read from a single record.
Challenge
A web SPA and a native Android app risked drifting into two different products.
How I solved it
Kept one backend contract as the source of truth for both clients, so feature parity was a matter of building the UI rather than re-deriving the domain.
Core features
- Event discovery
- Artist profiles
- Booking system
- Native Android app
- Venue management
- User reviews
Results & impact
Booking moved out of DMs and phone calls into a structured flow, with artists getting discoverable profiles, venues getting a way to publish availability, and fans getting one place to find live music — reachable from both the web and a native Android app.
What I learned
- On a marketplace, modelling the shared object once and projecting per-role views beats building three parallel data models.
- Native and web clients stay in parity when the contract, not the UI, is treated as the product surface.
