GradPath
A graduate-school application tracker — designed and built end to end, solo, with AI-native engineering. From the Prisma schema to the Tailwind spacing, every decision was made and verified by one person.
Overview
Graduate-school applicants routinely juggle three to six applications at once — each with its own deadlines, task checklists, and document requirements, spread across university portals, spreadsheets, and email threads. My friends and I lived this chaos while applying to postgraduate programs; the pain wasn't hypothetical.
GradPath was built to solve it: one workspace that tracks every application, auto-generates the task checklist per school, and keeps the supporting documents in one place. AI-assisted feedback on the Statement of Purpose and CV is the flagship feature lined up for the next release.
What makes it a design-engineering project rather than a design project is simple — I didn't hand off a spec. I designed it and shipped it, using AI-native workflows to build the thing I designed.
The application wasn't the hard part.
Managing six of them was.
Every university wants different documents, on different deadlines, through a different portal. Applicants don't struggle to write an application — they struggle to keep six of them straight without dropping a recommendation letter, a transcript, or a fee deadline.
GradPath replaces the spreadsheet-and-email sprawl with a single object model: everything belongs to an Application — its tasks, its documents, its deadlines, its progress — so there's one predictable place to look instead of five.
The conditions this was built under
The constraints weren't background detail — they shaped nearly every decision that follows.
- Solo & self-funded — no team, no dedicated QA, no design partner. Every decision, from database schema to spacing, was made and verified by one person.
- Built in the margins — alongside paid client work (Parousia West Africa, ALN/PAGExpress) and an MSc course load. Development happened in focused sessions, not full-time sprints.
- Real third-party dependencies — Clerk (auth), Supabase (Postgres + storage, Frankfurt), Anthropic (AI review), Flutterwave (payments), Vercel (hosting), each with its own failure modes to design around.
- Free-first go-to-market — a deliberate choice to launch without payments and validate demand, which meant every cost-generating feature needed hard, server-side limits before a single user could be trusted with it.
The decisions that mattered
The interesting part of this project isn't the screens — it's the judgment calls a solo builder has to make when design, engineering, cost, and legal risk all land on the same desk.
Refusing to stop at the first plausible fix
The app was slow on every page load. The obvious culprit was redundant Prisma queries — each page called user.findUnique and then application.findMany separately. Consolidating them into one nested query was a real improvement, but load times barely moved.
Rather than accept a partial win, I kept digging — and found the actual root cause: Vercel's serverless functions were deployed in Washington D.C. while the Supabase database lived in Frankfurt, so every query was making a transatlantic round trip no matter how well it was written. Moving the Vercel function region to Frankfurt fixed what query optimisation couldn't. The lesson generalised: a plausible fix that doesn't fully resolve the symptom is a signal to keep digging, not a place to stop.
Cost protection before feature polish
Before any public-facing polish, I verified that the free-tier limits were enforced server-side, in the API routes themselves, not just as a UI restriction a technical user could bypass. The 5-application cap is live; the daily AI-review limit is already wired into the review route ahead of the v2 launch.
That guardrail-before-feature order is deliberate: AI Review will call the Anthropic API on my own credit, so an unenforced limit isn't a hypothetical — it's a real, uncapped cost exposure. The cap goes in before the feature ever reaches a user.
Product safety over a "cooler" landing page
An early landing-page direction called for real university crests (Leeds, TU Delft, Edinburgh, Toronto, ETH Zürich) in a "trusted by" row. I rejected it deliberately: displaying another institution's trademarked crest implies a partnership that doesn't exist — a legal risk, and a trust risk the moment a sharp user notices.
The section was rebuilt with self-designed crest marks and, ultimately, national flags — visually strong, legally clean, and honestly labelled ("for applicants targeting programs like…" rather than "trusted by").
Prototype before touching production
The full landing redesign — an animated typing headline, a live task-checkoff illustration, an elevated feature grid — was built and iterated as a standalone HTML prototype first, reviewed and revised several times, before a single line of the production markup.ts / landing.css / LandingClient.tsx was touched.
That caught an inconsistent accent colour, an off-brand button style, and a broken visual element while they cost nothing to fix — rather than after they were live. It became the review habit I wish I'd adopted on day one.
Six screens, wired to real data
Every screen reads live, Prisma-backed application data — no placeholder content, no static mockups.
Dashboard
The command centre — active applications, upcoming deadlines, and overall progress surfaced at a glance, so the most important information comes forward instead of being searched for.
Applications
The core workspace. Create, organise, and monitor multiple university applications, each a centralised record holding its own progress, requirements, and supporting information.
Tasks
Each application auto-generates its checklist — request references, upload transcripts, write the statement, pay the fee — breaking a large application into steps with clear visibility into what's still outstanding.
Documents
Supporting files live alongside their application, in Supabase storage, instead of scattered across cloud drives and download folders — less context switching, faster retrieval.
AI Review — flagship, shipping in v2
The next major release: a three-stage pipeline — upload → analyse → annotated report — designed to run client-side PDF/DOCX text extraction (pdfjs-dist, mammoth) and return a rubric-scored review of the Statement of Purpose or CV, with clarity, structure, and impact broken out. It's architected but deliberately gated: the surface ships a considered "coming soon" state rather than a half-built feature, and its cost guardrail — a server-side daily limit — is already wired into the route ahead of launch (see decision 02).
Settings — real account operations
Profile editing, notification preferences, full data export, and account deletion — each backed by its own API route rather than a cosmetic form. Export and delete being real operations is a small but deliberate trust signal for a product that holds someone's application data.
Landing page
A typing hero that cycles through GradPath's core promises, an illustrated dashboard mock that animates its own task checklist, an elevated feature bento grid, an AI-review spotlight, and the legally-clean trust row from decision 03. Built prototype-first, then ported to production.
Home-screen app icon
A traced, pixel-accurate reproduction of the brand mark — not a redraw — shipped with a web manifest so the PWA opens full-screen from a phone home screen, with no browser chrome.
What's true so far — and what isn't yet
An honest case study separates what's verifiable from what's still a claim. This one describes build quality and engineering judgment — not market validation, because launch hasn't happened yet.
Verifiable
- Page loads improved after the Vercel function-region fix; the site now responds from the correct region
- The free-tier application cap is enforced in the route code — inspectable, not self-reported; the daily AI-review limit is wired in ahead of the v2 launch
- Privacy Policy and Terms of Service are live and linked from the footer, ahead of enabling paid plans
Not claiming yet
- The product is feature-complete for a free-first soft launch but not yet open to the public
- No usage, retention, or conversion data exists yet — that evidence doesn't exist because launch hasn't happened
- The highest-value next step is a public launch with basic analytics (already wired in) to generate real signups and activation numbers
What I'd do differently
Building entirely solo meant some early architectural choices — like splitting the landing page across three separate files (markup, styles, client logic) — made sense at the time but added real friction when the whole page needed a coordinated rebuild later. A more modular structure from day one would have made that redesign faster and safer.
It's also clear in hindsight that a couple of small bugs — an orphaned "add application" page still linked from the dashboard, a CSS-scoping mistake that nearly leaked landing styles into the rest of the app — would have been caught immediately by a second reviewer.
Solo building means moving fast, but it also means you're your own only safety net. The prototype-first habit I eventually adopted for the landing page is exactly the kind of lightweight review discipline worth building in earlier rather than later.