EventHub
EventHub is a luxury event-planning marketplace built during a software training program with SpaceTech, an Alexandria-based software house and tech training provider. Three sub-teams worked in parallel on a Next.js frontend, a .NET Clean Architecture backend, and an AI planning assistant, serving three distinct roles: customers booking events, vendors offering services, and admins running the platform. I was team lead, worked hands-on in the frontend, helped the backend team where needed, and connected the AI Planner into the frontend experience.
A stronger hero that frames this project like a real case study instead of a plain information page.
Impact
Overview
EventHub was built during a structured training program with SpaceTech, a software house and training provider in Alexandria that runs full-stack, frontend, backend, and AI tracks. Rather than a single tutorial-style build, the training split trainees into sub-teams working across separate repositories — a Next.js frontend, a .NET backend, and an AI assistant — to mirror how a real product team operates.
The product itself is a luxury event-planning marketplace: hosts book vetted vendors for weddings, corporate galas, private dining, and decor, vendors list and manage their services, and admins run the platform behind the scenes. As team lead, I was responsible for keeping the three sub-teams aligned, while also working hands-on in the frontend, supporting the backend team when they needed a hand, and owning the connection between the AI Planner and the rest of the app.
Problem
With three separate repos and sub-teams building in parallel, the biggest risk wasn't any single feature — it was integration drift between the frontend's expectations, the backend's actual API shape, and what the AI assistant could realistically support.
The backend and AI services were still catching up to the frontend for large parts of the build, so the team needed a way to keep building real screens without waiting on every endpoint to exist first, while still delivering three genuinely different user experiences (customer, vendor, admin) that all had to feel like one coherent product.
Key Features
- Customer marketplace: vendor discovery and search across categories (Weddings, Corporate Galas, Private Dining, Decor & Florals), vendor profiles with a 40-point vetting badge, ratings, and pricing
- Three-tier premium packages (Intimate, Signature, Grand Estate) with concierge-style positioning for higher-touch bookings
- Multi-step booking wizard: date/guest selection, package choice, checkout, and confirmation, plus bookings history and payment method management
- AI Planner chat interface for guided event planning, wired into the same booking and vendor data as the rest of the app
- Vendor entry point ("Partner With Us") for vendor registration and profile completion, with a fuller vendor management dashboard (services, availability, booking requests, analytics) scoped as a next phase
- Full admin portal: dashboard with platform KPIs, user management, vendor directory and approval queue, analytics charts, and reports
- Auth and role-based route guards separating customer, vendor, and admin access
Timeline
Split the platform into customer, vendor, and admin experiences and organized the frontend, backend, and AI sub-teams around them.
Set up the Next.js App Router structure, design system, auth flows, and typed API service layer.
Built vendor discovery, the booking wizard, premium packages, and the customer profile experience.
Connected the AI Planner chat into the frontend's booking and vendor data, and worked with the backend team on request/response shapes as endpoints came online.
Shipped the full admin portal: dashboard, user management, vendor directory, analytics, and reports.
User Workflow
- Customers browse and filter vendors by category and city, compare vendor profiles and pricing, and move through the Reserve → Checkout → Success booking wizard or choose one of the three premium packages for a more curated experience.
- The AI Planner offers a chat-based entry point into the same booking and vendor data the rest of the app uses, so a customer can describe an event and get guided toward the right vendors and package.
- Vendors start from a dedicated "Partner With Us" flow to register and complete their profile; the fuller vendor dashboard for managing services, availability, and incoming booking requests was scoped as follow-up work beyond the training window.
- Admins operate a separate portal for platform-wide oversight: reviewing and approving vendors, managing users, and monitoring bookings and performance through analytics and reports.
- Behind all three experiences, a typed service layer in the frontend talks to the .NET backend, falling back to typed fixture data for endpoints the backend hadn't shipped yet so screens stayed usable while integration caught up.
Architecture
- The frontend is a Next.js 16 App Router application (React 19, Tailwind CSS v4, Radix UI primitives) organized by feature: auth, vendor browsing, booking, AI planner, vendor onboarding, and admin.
- The backend follows Clean Architecture in C# (.NET), split into API, Application, Domain, and Infrastructure layers, giving the team a clear boundary between HTTP concerns and business logic.
- The AI assistant runs as its own service, designed to plug into the same booking and vendor data model rather than being bolted on separately — this was the seam I worked on most directly, alongside my frontend work.
- A shared typed service layer (`auth.service`, `booking.service`, `vendor.service`, `event.service`) is where frontend, backend, and AI work had to agree on contracts.
Technical Focus
- Led the team across frontend, backend, and AI sub-teams: setting priorities, agreeing on API contracts before every backend endpoint existed, and unblocking teammates when work crossed repo boundaries.
- Built the core customer experience in the frontend — vendor marketplace, premium packages, and the booking wizard — plus the admin portal's dashboard, vendor directory, and analytics views.
- Connected the AI Planner to the frontend's booking and vendor service layer so its chat-based suggestions map to real, bookable data instead of being a disconnected demo.
- Picked up backend tasks alongside the .NET team when the frontend was blocked on an endpoint, to keep both sides of the build moving.
- Designed the frontend's mock-data strategy so screens could ship ahead of backend readiness, using field names that mirror real backend entities to keep the eventual swap-over low-risk.
Challenges Solved
- Keeping three parallel repos (frontend, backend, AI) integration-compatible without constant blocking, especially while the backend's public endpoints were still being built out.
- Leading a team through unclear or shifting scope — the vendor's own management dashboard, budget planner, and booking history were intentionally left open and had to be sequenced rather than rushed.
- Balancing my own hands-on delivery work (frontend, AI integration, backend support) with team-lead responsibilities like unblocking teammates and reviewing how pieces fit together across three very different user roles.
Deployment
- The frontend is deployed to Vercel; the backend and AI services were developed and run for the training program rather than kept on permanent public infrastructure.
Outcome
EventHub is the clearest example in my portfolio of leading a team through a multi-service, multi-role build — not just writing frontend code, but keeping frontend, backend, and AI work integration-ready across three separate repositories while three distinct user experiences (customer, vendor, admin) took shape.
It also reflects real-world product conditions from a SpaceTech training engagement: incomplete backend endpoints, evolving scope, and the need to make pragmatic calls (like the mock-data strategy) so the team could keep shipping.