Project 1 of 5
2026 · Web apps
Zumelia
My own social product — Meet. Collaborate. Earn. Built as founder, not a client deliverable.
- Role
- Founder & builder
- Outcome
- A living product identity — collaboration and growth in one platform.
- Stack
- Next.jsSupabase AuthSupabase DBSupabase StoragePaystackGroqLiveKitVercel
Project overview
My own social product — Meet. Collaborate. Earn. Built as founder, not a client deliverable.
- Product vision owned end to end
- Social collaboration flows
- Auth, data, and storage on Supabase
- Payments via Paystack
- AI features via Groq (server-side)
- Realtime media via LiveKit
- Live intro walkthrough
Problem
Build a social product where people can meet, collaborate, and earn — without bolting auth, storage, payments, AI, and realtime onto fragile one-off scripts.
Solution
Ship on Next.js + Vercel with clear service boundaries: Supabase for auth/data/storage, Paystack for payments, Groq for AI, LiveKit for realtime media.
Technology
Next.js
Product UI, routing, and server orchestration
Supabase Auth
Identity and sessions
Supabase (PostgreSQL)
Persistent product data
Supabase Storage
Media and file assets
Paystack
Payment collection for earn flows
Groq
Low-latency on-product AI
LiveKit
Realtime collaboration / media
Vercel
Hosting and deployment
Engineering challenges
- Keeping API keys (Groq, payment secrets) off the client
- Treating payment success as unverified until server confirmation
- Separating relational data concerns from realtime media sessions
- Iterating as founder while the product is still evolving
Engineering decisions
Why Next.js?
- Problem
- Need a product shell that can ship UI and server logic together on Vercel.
- Decision
- Next.js
- Options considered
- Separate SPA + API · Next.js App Router · Remix
- Reason
- Fits Vercel deployment and keeps product UI + server routes in one codebase.
- Trade-off
- Framework coupling — migrations later cost more than a thin SPA.
Why Supabase?
- Problem
- Need auth, Postgres, and storage without operating raw infrastructure day one.
- Decision
- Supabase (Auth + DB + Storage)
- Options considered
- Custom Node + Postgres · Firebase · Supabase
- Reason
- One platform for identity, relational data, and file storage with RLS patterns.
- Trade-off
- Vendor abstractions — deep DB edge cases still require SQL fluency.
Why Paystack?
- Problem
- Earn flows need reliable payment collection for the target market.
- Decision
- Paystack
- Options considered
- Stripe only · Manual transfers · Paystack
- Reason
- Strong regional fit and familiar checkout patterns for African markets.
- Trade-off
- Must harden webhooks and server verification like any PSP.
Why Groq for AI?
- Problem
- Product AI features need low latency without shipping keys to clients.
- Decision
- Groq (server-side)
- Options considered
- OpenAI only · Self-hosted · Groq
- Reason
- Fast inference suitable for interactive UX; keys stay on the server.
- Trade-off
- Provider lock-in risk — mitigated with OpenAI-compatible adapters.
Why LiveKit?
- Problem
- Collaborate/meet experiences need realtime media.
- Decision
- LiveKit
- Options considered
- Raw WebRTC · Agora · LiveKit
- Reason
- Purpose-built realtime media with clear token/room model.
- Trade-off
- Another moving part in ops — worth it vs building media infra.
Results
Public live product at zumelia.site with an intro walkthrough. Specific user/revenue metrics are not published here.
What I would improve
If rebuilding toward much larger scale: deepen caching and read-path design, harden rate limits/abuse controls, add stronger observability, review indexes/RLS, and ensure Paystack webhooks are fully idempotent. These are engineering priorities — not claims about current scale.
