UNavigate
A college visit recording app built for a non-technical founder who runs a college counseling business. Configuration-driven forms, offline-first sync, 7,000+ colleges. Currently in development.
My girlfriend's mom runs a college counseling business. She wanted a way for her students to record their college visits in an easy, fun-to-use app on their phone. For her, it's her vision coming to life. For me, it's a lesson in working with a non-technical founder and bringing someone else's idea to life without diverging from their vision.
When she first had the idea, I set her up with a starter prompt in Claude. I told her to pitch her initial vision, then let Claude ask her questions to flesh it out. She had a lengthy conversation where she defined the requirements in natural language and even got a basic prototype through an HTML artifact. I was able to take those two things — her conversation and prototype — and feed them into my own Claude session to refine the scope, generate detailed specification documents, and bring them to Claude Code for implementation.
It's really cool to see her eyes light up when we bring her idea to life.
During development, Claude identified that the founder had already changed the UI forms multiple times. So I asked Claude what our architectural options were, knowing that the first prototype would likely not be the UI that made it to production. The answer: make the forms configuration-driven. Each form field — ratings, text inputs, photo uploads, sliders — is defined as a JSONB schema in Supabase, not hardcoded in React. The entire evaluation structure can be modified without deploying a new version. When the founder wants to add a question, change the rating scale, or reorder sections, it's a data change, not a code change.
Campus WiFi is unreliable. The app stores everything locally in IndexedDB first, then syncs to Supabase when connectivity returns. Writes go into a queue that replays in order. The UI is always responsive because it reads from the local store, not the network. You can complete an entire college visit evaluation on airplane mode and it syncs when you're back online.
Students and parents have different roles with different views. Parents can manage the visit schedule and see aggregate comparisons. Students fill out evaluations and add photos. Both contribute to the same visit record. The auth system supports parent and student accounts linked together, so a family shares data without sharing a login.
The app ships with a comprehensive college dataset — searchable by name, location, size, and type. When you plan a visit, you select from real institutions with pre-populated metadata. The search is instant because the dataset is loaded client-side and filtered in memory, no network round-trip for each keystroke.
┌─────────────────────────────────────────────┐
│ Next.js 16 (App Router) │
│ │
│ ┌──────────────┐ ┌──────────────────┐ │
│ │ React UI │ │ IndexedDB │ │
│ │ (config- │◄─►│ (offline store │ │
│ │ driven │ │ + sync queue) │ │
│ │ forms) │ └────────┬─────────┘ │
│ └──────────────┘ │ │
│ ┌─────────▼──────────┐ │
│ │ Sync Engine │ │
│ │ (queue replay) │ │
│ └─────────┬──────────┘ │
└──────────────────────────────┼─────────────┘
│
┌────────────▼────────────┐
│ Supabase │
│ │
│ ┌───────────────────┐ │
│ │ PostgreSQL │ │
│ │ (JSONB schemas, │ │
│ │ visits, users) │ │
│ └───────────────────┘ │
│ │
│ ┌───────────────────┐ │
│ │ Auth (RLS) │ │
│ │ parent/student │ │
│ └───────────────────┘ │
└─────────────────────────┘The frontend is Next.js 16 with the App Router. Supabase provides the backend — PostgreSQL for storage, Row Level Security for multi-tenant data isolation, and built-in auth for the parent/student role system. The JSONB schema pattern means form configurations live in the database alongside the data they collect.
The offline layer sits between the UI and Supabase. Reads always hit IndexedDB first. Writes go to the local store immediately (optimistic updates), then queue for sync. The sync engine handles conflict resolution with a last-write-wins strategy, which works because visits are typically edited by one person at a time.
This wasn't a theoretical design choice. The founder had already changed the form structure multiple times during early conversations. Claude flagged this pattern, and I asked what our options were knowing the first prototype wasn't going to be the production UI. Configuration-driven forms mean one component tree renders any form shape. When the founder iterates on questions — and she will — it's a database update, not a pull request.
The deciding factor was the Supabase MCP integration with Claude Code. Being able to interact with the database, run migrations, and manage the backend directly through the AI coding agent made development and deployment a breeze. Row Level Security policies handle the multi-tenant isolation at the database level, and the built-in auth system handles the parent/student role model without custom middleware.
I've been thinking about how to teach normal people to use AI. Their presupposition is that they command it like a computer. I first thought we had to teach people new skills, but the truth is that most people already possess the skills — they just don't direct them at the AI. I ask people: “If you had 30 minutes with an expert on your problem to help you solve it, what would you ask them?” Then I say, now type exactly that into that box. The results change the way they use AI. The founder's Claude conversation produced requirements that were better-scoped than most PRDs I've seen from technical people.
This project is still in active development between the founder and me, so I'm still learning as I go. The biggest lesson so far is about respecting someone else's vision. When you build for yourself, you are the requirements. When you build for a non-technical founder, you have to resist the urge to “improve” things they didn't ask for and stay disciplined about building what they described.