Case study
Elevent
A live event-operations platform for food and retail vendors at UAE events. I’m its sole developer: I own the frontend, and I shipped and run the whole product.
- Role
- Frontend Engineer (Sole Developer)
- Timeline
- Jan 2026 – present · live since Oct 2026
- Platforms
- Web app; iOS and Android app in progress
- Live site
- elevent.ae (opens in new tab)
The problem
Events bring in dozens of food trucks and kiosks, each with expiring licences, a contract, a POS terminal and sales to reconcile. Elevent replaces the spreadsheets with one platform, from vendor onboarding to payouts, with a portal for each of its seven user types: vendors, event clients, organizers, food-safety auditors, finance, freelancers and admins.
Architecture
- The browser only talks to the Next.js app, which keeps the session in an httpOnly cookie and proxies every API call.
- The API has no public ports; the web and mobile apps reach it through a Cloudflare Tunnel.
- Daily backups with 7-day point-in-time restore, plus nightly encrypted off-site copies.
My role
Owned
- The entire frontend: 120+ pages, the design system on shadcn/ui and Tailwind CSS, role-based portals and the typed API layer.
- The full product in production: backend, database, hosting, CI, deploys and monitoring, built with AI-assisted development and my own review and testing.
Decided
- Auth: session tokens in httpOnly cookies behind a Next.js proxy.
- Permissions drive the UI; the API enforces them.
- Hosting: Cloudflare edge for the web app, DigitalOcean for the API and database.
- Money as exact decimals, never floats; business dates in UAE time.
Three frontend decisions
Tokens never touch JavaScript
Every browser request goes through a Next.js proxy that reads the session from an httpOnly cookie, and tokens are stripped from API responses. An XSS bug can’t steal a token the page never sees, and forged requests fail an origin check plus a double-submit token. The cost is one extra hop per call; the gain is one place for auth, token refresh and errors.
One permission source drives the UI
The app loads the user’s permissions once. A <PermissionGate> component and permission-filtered navigation decide what each of 13 roles sees, and the UI fails closed if that call fails. A new role means granting permissions on the server, not editing pages, and the API still enforces every check.
Fix the primitives, then the pages
For the responsive pass across 120+ pages, I fixed the shared components first, then swept pages at five widths from 360 to 1280 px. Most overflow bugs came from a few primitives. A Playwright check now flags any page that scrolls sideways.
A production bug, and the fix
iPhones wouldn’t play the homepage video
On the live Cloudflare platform, Safari on iPhone never started the homepage video. Safari requests video in byte ranges and expects 206 Partial Content, but Cloudflare’s static serving ignored the Range header. I added a small route that answers range requests with 206 and the right Content-Range, verified it on the production build, and shipped it before the video reached users.
Results
- live in production
- Oct 2026
- pages in the web app
- 120+
- with 45 fine-grained permissions
- 13 roles
- p95 for interactive API endpoints
- < 200 ms
- vendor-approval queue after fixing an N+1 query
- 1.36 s → 0.17 s
- automated tests run in CI on every push
- 700+
Stack
- Frontend
- Next.js (App Router), React, TypeScript, Tailwind CSS, shadcn/ui, React Hook Form, Zod
- Backend
- FastAPI, PostgreSQL, Alembic
- Platform
- Cloudflare Workers (OpenNext), DigitalOcean, Docker, GitLab CI
- Mobile
- React Native, Expo (in progress)
Want to go deeper?
I’m happy to walk through the architecture and the trade-offs in an interview.
Get in touch