Building EventDocs.io with Kotlin Multiplatform + Firebase
When I started EventDocs.io, I wasn’t trying to choose the “perfect” tech stack. I just wanted to build something real — fast. After years working in Android, I knew one thing for sure: if I could use the tools I already understood deeply, I could get an MVP in days instead of months.
That’s what pushed me toward Kotlin Multiplatform. Most people reach for React or Svelte when they build a web app. I opened a KMP project, wrote a few composables… and suddenly it felt like home. The same patterns, the same mental model, the same flow as Android — just running in the browser. Within a few hours I had screens rendering, state flowing, and the beginnings of a real product.
The difficult parts nobody mentions
Of course, the honeymoon didn’t last forever.
There’s always a moment when the easy wins run out and you hit the parts the framework doesn’t solve for you.
For me, that moment arrived when I tried to make the app behave like an actual web app: fast initial load, URLs that sync with navigation, selectable text, links that behave like links. These are the things you never think about until they’re missing. I ended up building a handful of tiny components — web-specific, slightly hacky, extremely useful — just to make Compose Multiplatform feel natural in the browser.
Once those pieces were in place, the whole project opened up. It stopped feeling like an experiment and started feeling like a tool.
Firebase and the invisible work
I paired KMP with Firebase for one simple reason: speed. Hosting, Auth, Firestore — everything I needed to ship quickly without reinventing half the backend.
The GitLive Firebase Kotlin SDK worked far better than I expected: no wrappers, no friction, and very few platform-specific quirks — except for a couple of Google Auth details that needed some extra handling. The real work was elsewhere — writing Firestore security rules that were both safe and flexible. If EventDocs was going to store teams’ tracking specs, it needed solid guardrails. That part took time, but once it clicked, the foundation felt solid.
A framework that rewards familiarity
There was one moment when everything shifted.
I had just finished wiring URL navigation into Compose and built a couple of tiny browser-specific helpers. I refreshed the page, clicked around, and for the first time the app felt… alive. Not a prototype, not a demo — a real product running entirely on Compose Multiplatform.
From that point on, development felt smooth. I used Carrd for the landing page because it was faster, and focused 95% of the effort on building the actual tool inside Compose. Only a few features — clipboard access, image imports, some URL handling — needed JS interop. Everything else stayed inside the KMP world.
Would I choose it again?
For this project, absolutely.
I shipped fast, reused my experience, and built something meaningful using a framework that still feels like both a challenge and a secret superpower.
If you're curious how a full web app behaves when built with Compose Multiplatform, you can try EventDocs here:
And if you're exploring KMP yourself — the good, the bad, the weird — I’m happy to share more.
