Convena — Event Registration & Management Platform

Role: Solo Developer & Product Owner Status: Live (Soft Launch) · 2025 Stack: Vue.js · Laravel · TailwindCSS Type: Independent Product

The Origin Story

Convena didn’t start as a new idea. It started as a realization.

Over the past few years, I built and maintained an event registration and management system for two Catholic NGOs — one in Jakarta, one in Makassar. The system ran end-to-end: online registration, Midtrans payment processing, QR-based usher check-in, WhatsApp messaging, email confirmations. At its peak, it handled events with 7,000+ participants. It worked. It scaled. Other organizations wanted it.

But it was never mine — not commercially, not architecturally. So I did what any solo builder eventually has to do: I took the platform back, cleaned it up, gave it a proper name, and started treating it like a product. That’s Convena.

The First Real Test

The first event running on the Convena brand: a Catholic revival event in Makassar, targeting ~2,000 participants through the platform. Not a soft internal pilot — a live event, real attendees, real organizing team depending on it.

The scope for this version was deliberately focused. Rather than activating every feature the underlying platform supports, the build cycle was spent on UX refinement — cleaner flows, a more polished interface, a better overall experience for both participants and organizers. The foundation already existed. What this launch needed was for it to feel trustworthy to people encountering it for the first time under a new name.

Where Reality Got in the Way

Two things didn’t go as planned — and both are worth documenting honestly.

Payment gateway integration hit a compliance wall. The original platform ran Midtrans smoothly, but activating it for Convena ran into taxation complexity that wasn’t worth shipping around. The pragmatic solution: unique codes. Every participant receives a code tied to their registration, and the organizing team manually verifies payments against it. More operational work for the team, but clean, auditable, and zero legal ambiguity. It goes into the backlog as a proper architectural item for the next version.

WhatsApp notifications got blocked. The new sending number used for Convena got flagged before the event — automated delivery stopped working. Fallback: manual WhatsApp sending by the organizing team. The event ran. But this one stings enough to demand a real solution: better number management, a more robust comms infrastructure, or a different channel strategy entirely.

Neither issue stopped the launch. Both went straight into the next version’s requirements.

Why It Goes Offline After the Event

Convena will be taken down once this event ends. That’s a deliberate product decision, not a failure.

What still needs to be built before Convena is ready to be a real product:

• Multi-organization support — proper tenant isolation so multiple orgs can run independently
• Pricing and billing model — figuring out how this works commercially
• Payment integration — with the right compliance setup, not a workaround
• Comms infrastructure — a WhatsApp and notification layer that doesn’t collapse under a new number

Shipping for this event was the right move. It stress-tested the platform at real scale under a real name, surfaced gaps that a staging environment never would have caught, and gave me the most honest form of requirements gathering there is: watching people actually use it.

The next version will be built on all of that.

What I Learned

There’s a particular kind of clarity you get from owning a product versus just building one. On client work, when something breaks, you fix it and close the ticket. When it’s yours, the postmortem lives in your backlog permanently — shaping every decision that comes next.

The WhatsApp incident and the payment workaround aren’t just incidents. They’re the two biggest items on Convena’s roadmap now, because real-world failure is a more reliable spec than anything I’d have written in advance.