Be My Guide
A request-broadcast platform that pairs visually impaired Norwegians with nearby sighted volunteer guides for running, hiking, and cross-country skiing.
- Next.js 16
- React 19
- TypeScript (strict)
- Tailwind CSS v4
- Neon Postgres
- Prisma
- Auth.js v5
- Web Push
- Upstash Redis
- Vercel BotID
- Resend
- Vitest
01 / Context
Visually impaired Norwegians can run, ski, and hike — but only alongside a sighted guide, and finding one is informal and ad-hoc: word of mouth, Facebook groups, and club rosters that have not been updated in years. Plenty of sighted people would happily guide a couple of times a month, but there is no low-commitment way to plug in. Be My Guide is a request-broadcast matching app that closes that coordination gap for two real Oslo archetypes: a participant who just wants company for a 5K, and a volunteer who wants to help without joining a formal club.
02 / My role
I am designing and building this solo, end to end — product scope, the accessibility-first UX, the data model, auth, and the real-time notification layer. It is currently in active development, with the data model, magic-link and Google auth, the request and matching flows, and admin guide-review under construction toward an MVP whose success bar is five approved guides and one real arrangement.
03 / Problem
The hardest design problem is trust and accessibility under low coordination friction: the experience has to meet WCAG 2.2 AA in both light and dark modes, work screen-reader-first for participants, and still feel calm rather than like a SaaS dashboard. The hardest engineering problem is fan-out — when a participant posts a request, every approved guide in that region with a matching activity type needs a push notification within seconds, without spamming anyone and without leaking personal contact details before both sides have agreed.
04 / Approach
On the design side I gave the two roles distinct entry points from the landing page, kept request creation to a single mobile-first form with native pickers for screen-reader friendliness, and deferred contact reveal until an arrangement is confirmed so phone and email stay private until they are needed. On the engineering side I modelled Users, Requests, Interests, and Arrangements in Postgres with the indexes the matching fan-out actually queries (region + verificationStatus for guide lookup), built notifications on the raw Web Push API with a hand-rolled service worker to avoid PWA bloat, gated every new guide behind manual admin review, and hardened the public endpoints with Upstash Redis rate limiting and Vercel BotID. Tokens and sessions run through Auth.js v5 with a database session strategy so sessions are revocable.
05 / Result
The build is in progress, but the architecture is already proving the duality I care about: an accessibility-first, deliberately calm interface sitting on top of a real-time, abuse-resistant matching backend. It is a genuinely hard product — broadcast matching, push fan-out, contact-privacy, and strict a11y all at once — and it is the clearest current example of how I work as a developer who designs.
More screens
