EventDocs.io

In my experience, they usually start much earlier, when events are loosely defined, named inconsistently, or never written down at all.

When definitions aren’t clear, numbers can be technically correct and still misleading. Everyone thinks they’re measuring the same thing, but the intent behind the data isn’t aligned.

Over time, this made me realize that documentation isn’t overhead. It’s what turns analytics into something teams can actually trust.

That’s the problem I’m trying to solve with EventDocs.io.

While building EventDocs.io, I spent a lot of time thinking about the tech stack. That part felt familiar and comfortable. What I’ve been much worse at, honestly, is distribution.

I don’t have an audience. I have a small X account, a few IndieHackers posts, and that’s about it. And that’s been a good reminder that choosing the “right” framework doesn’t magically solve the hard part of getting the product in front of people who actually need it.

The stack only helped in one way. It let me build and iterate without friction. Everything else, explaining the problem clearly, finding the right users, earning attention, is still something I’m figuring out.

I wrote more yesterday about the technical side of how I built EventDocs.io, in case that context is useful. But this is the part I’m actively learning now. Building is only half the job.
→ https://www.indiehackers.com/post/building-eventdocs-io-with-kotlin-multiplatform-firebase-c2Wg9ghQWtNZwIBg54hB

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:

👉 https://app.eventdocs.io

And if you're exploring KMP yourself — the good, the bad, the weird — I’m happy to share more.

After years working with product and data teams, I noticed something:

Dashboards don’t usually break because of Mixpanel or GA4.
They break because teams define events differently, or not at all.

• Inconsistent event names across teams.

• Undocumented parameters and values.

• Specs scattered across Slack, Notion, Jira and spreadsheets.

I built EventDocs.io to fix that.

It’s a documentation-first workspace for analytics tracking — so product, dev, marketing, and data can all align before dashboards start lying.

Do you clearly define your tracking events upfront — or fix things after launch when dashboards break?

After years of dealing with scattered spreadsheets, outdated Jira tickets, and chaotic Slack threads just to define analytics events, I finally decided to build the tool I always wished existed.

EventDocs.io is a clean, structured space to define, organize, and share your analytics event specs — before implementation begins.

Instead of emailing tracking plans back and forth or guessing what the latest version is, you get a single source of truth your whole team can trust — from product and marketing to dev and data.

It’s 100% documentation-focused:
❌ No SDKs
❌ No data collection
✅ Just well-defined, versioned specs

Think of it like Figma, but for tracking plans.

🧪 I’m actively shaping it with early users. If you’ve ever struggled with messy tracking workflows, I’d love your feedback.

Check it out → eventdocs.io