Hulofuse

There were plenty of ways to find an event and turn up with a group of strangers. The interesting problem started afterwards.

Two people might get on brilliantly for an evening and never see each other again. Friendship needs repeated contact, so Hulofuse couldn’t stop at attendance.

We built it to find out what could happen if the product stayed involved. Hulofuse launched across the Bay Area, grew to more than 800 users, and brought people together at real events.

The difficult part was not building another social app. It was everything that had to happen around a meeting: deciding who might get along, forming useful groups, managing events and waitlists, giving people somewhere to talk, learning what happened afterwards, and using those signals to make the next introduction better.

• 01Understand enough about each person to make a useful introduction.
• 02Turn possible compatibility into a real event and a workable group.
• 03Carry the event through capacity, chat, attendance, and follow-up.
• 04Use what happened to improve the next opportunity to meet.

Public, private, recurring, curated, invite-only, and club events have different rules. RSVP state covers capacity, maybe responses, approvals, waitlists, and promotion when a place opens. Recurring events retain occurrence-specific state through chat, grouping, reminders, attendance, and follow-up.

1. 01Find and join the right event
2. 02Meet a compatible group
3. 03Record what actually happened
4. 04Create a reason to meet again

A progressive Big Five questionnaire feeds compatibility and hybrid recommendation systems. A separate clustering path turns profile and behaviour data into candidate groups. RSVP, direct interaction, attendance, no-show state, post-event answers, and group outcomes can all become signals rather than leaving the original match untouched.

Realtime chat follows the same product rules. Event-chat writes are checked against the caller’s attendance state in another service. Recurring occurrences retain separate rooms, and alerts, reactions, presence, and push notifications carry the conversation through the client.

That eventually became a Flutter client for Android and iOS, three Go services, and a data architecture spanning PostgreSQL, PostGIS, Redis, Elasticsearch, Kafka, and S3. PostgreSQL holds the authoritative product state while dedicated consumers keep search and realtime projections current.

The services deploy behind Traefik across three API hosts. Five CDC consumers run through Nomad. Releases verify both service health and the exact running commit, while Sentry, Firebase Analytics, health checks, and consumer metrics provide evidence of what is happening after deployment.

Hulofuse has been live for more than ten months, exceeded 800 users, and has hosted real events in the Bay Area.

Continued use exposed a route-prefix outage, stale search and cache projections, RSVP and waitlist edge cases, notification routing problems, per-host release mistakes, and authorisation gaps around media and direct messages. The architecture, safeguards, and tests changed as those cases appeared.