Eventoo — voice-first event management

The problem

Event planners spend hours on data entry. A wedding planner finishes a client call, then transfers everything to a CRM by hand: vendor list, guest counts, dietary restrictions, venue details, deadlines. The phone call itself was the productive part — the typing afterward is friction. Worse, planners run multiple events in parallel and need different levels of access for their staff vs. their clients (a client should see their event's vendor list but not your other clients' rates).

PairForge — the AI-native product studio I co-founded with Prachi — needed a first product. We picked event management because: (1) operational pain is concrete and measurable, (2) AI voice-to-form has obvious application, and (3) the market has incumbents but none built for the post-LLM workflow.

The approach

Voice-to-form as the core UX

Open the app, hit record, describe the event: "Sarah & Mike wedding, March 15th 2027, 180 guests, Royal Pune. Venue confirmed, catering is Kapoor's, photographer pending." In under 2 seconds, structured fields populate. Edit anything that's wrong, save. Skipping the form-fill step is the entire pitch.

Implementation: Groq Llama 3.3 with a structured-output prompt that maps free speech to the event schema. Groq's inference speed (<500ms typical) was the unlock that made this feel real-time vs. the long wait you get from cloud LLMs. Fallback to manual form fields for users who prefer typing.

Role-based access, modeled from day one

Three roles with surgical permissions:

• Manager — full CRUD on their own events, view team performance, billing
• Employee — assigned events only, can update tasks but not pricing
• Client portal — read-only view of their event, can comment on vendor selections, no internal notes

Permission boundaries enforced at the FastAPI route level (not just the UI) so a manager can't accidentally expose client data through API misuse.

Stack: Flutter + FastAPI + Postgres

Picked the most boring durable stack for an MVP. Flutter for one codebase across iOS + Android. FastAPI for the backend because Pydantic models double as both API schema and validation. PostgreSQL because it's fast enough for everything we'll need. Firebase Auth for Google Sign-In (saves us writing auth flows).

No microservices. No GraphQL. No premature scaling. The entire backend is one FastAPI app, one Postgres instance, one Docker container per service, Traefik in front for routing and TLS.

The hard parts

Voice parsing accuracy. Llama 3.3 hallucinates dates if the speaker is vague. Solution: a strict JSON schema with null defaults for unparseable fields, and a confidence score per field. UI shows yellow underline on low-confidence parses so users know to verify.

Client portal scope creep. Clients started asking for messaging, file uploads, contract e-signature. Held the line: v1 is read + comments only. Other things go in v2 after we have 10 paying customers.

Deployment pipeline. First end-to-end PairForge deploy. Built the pattern we'll reuse for every future product: Docker containers behind Traefik, deployed via GitHub Actions to a Hetzner box, health-checked by an automated watchdog that pages on downtime, backups to Cloudflare R2.

The outcome

• 3 weeks from blank repo to live beta — single dev (me) full-time, Prachi handling vendor outreach and design feedback
• Voice-to-form working with sub-2-second end-to-end latency (Groq + structured output prompt)
• 3 role tiers enforced at API + UI layers
• Full deploy stack running on a single Hetzner box: Traefik + FastAPI + Postgres + Flutter web build, automated CI/CD, watchdog monitoring
• Foundation pattern that subsequent PairForge products will reuse — saves ~1 week of devops setup per future product

Eventoo is the first product in PairForge's portfolio. The plan: get to 100 paying event planners, then either sell the product or maintain it while building the next one.