Nexus Portal
Multi-tenant SaaS for academic mentorship. Designed, built, and shipped in 11 days as sole developer.
Overview
I designed, built, and deployed Nexus Portal in 11 days as sole developer. It's a multi-tenant SaaS for Nexus Premedical Advising, a US mentorship business connecting pre-med students with admissions mentors. The platform unifies four user roles (admin, mentor, student, parent) under one login with Stripe billing, GoHighLevel CRM sync, Google Calendar integration, and a real-time KPI dashboard. Every milestone was approved on first or second review with zero critical bugs.
The challenge
James Ramos, the founder, was running Nexus Premedical Advising across five tools that didn't talk to each other: Google Sheets for tracking students, manual invoicing, email threads for scheduling, and GoHighLevel as a CRM. New parents had no self-service onboarding. Scheduling required back-and-forth emails. Billing didn't support package pricing. There was no visibility into churn, revenue, or mentor costs. Parents had no way to see their child's progress.
He needed a unified platform that every stakeholder (admins, mentors, students, and parents) could use from a single login.
The reframe
The product wasn't a CRM, a billing tool, or a scheduling tool. It was a single shared reality for four different stakeholders.
Once I framed it that way, I couldn't ship a CRM with billing bolted on. I had to ship four portals that share the same underlying data and let each role see exactly what they need. Admins need control of everything. Mentors need their roster and earnings. Students need to book sessions. Parents need to pay and see progress. Same data, four very different jobs.
Key decisions
Four portals sharing one data model
Most multi-tenant SaaS treats roles as permission flags on the same screens. I built four genuinely distinct portals with their own information architecture, while every screen reads from the same Postgres schema with Row-Level Security enforcing access. Tradeoff: more screens to maintain. Win: each role gets a UX designed for their actual job, not a stripped-down version of the admin view.
Unified pricing: one plan, two payment shapes
James wanted a single pricing tier per package level that could handle both monthly subscriptions and one-time pay-in-full payments. The package price auto-calculates based on the student's grade level and how many months remain until their next academic phase transition (August 1st). Formula: Monthly Price × Months Remaining × (1 − Discount%). Tradeoff: significant complexity in the billing layer, plus a 24-hour cancellation policy and an August 1st grade-promotion cron to maintain. Win: parents see one clear choice at checkout instead of a dozen SKUs to compare. Package students see “Paid in Full”, monthly parents see upcoming charges, and students stay locked out until their parent pays.
Two-way GoHighLevel sync, never enter data twice
James already lived in GoHighLevel for lead nurture. I built a two-way webhook sync so portal accounts get created when he tags a lead in GHL, and changes inside the portal push back as custom contact fields. The smart bit: parents don't get their payment email until both the student and parent are tagged AND a plan is assigned, so the order of tagging doesn't matter. Tradeoff: webhook idempotency was painful to get right. Win: James never has to enter data twice and onboarding kicks off the moment a lead converts.
Session booking that handles its own calendar
Mentors set weekly availability windows and date-specific overrides. Students browse open slots and book sessions, which automatically create Google Calendar events with Meet links, send email confirmations to all parties, enforce booking cutoffs, and trigger 1-hour reminder emails. Mentor pay auto-updates when students change plans. Tradeoff: I gave up the flexibility of integrating with mentors' existing calendars (everyone has to live inside the portal's scheduling). Win: zero double-booking, zero email-thread back-and-forth, and the cancellation policy enforces itself.
A KPI dashboard the founder actually opens
Real-time business analytics: MRR, gross profit, lifetime gross profit per student, CAC, LTV, ROAS with manual adspend input, churn rate, sales velocity, cost of service, average retention time, and effective bill rate. Each KPI card is clickable, expanding into a monthly trend chart. A summary table breaks down all metrics by month. Tradeoff: I built every KPI from scratch instead of dropping in an off-the-shelf analytics tool. Win: James opens this every morning instead of running spreadsheets, and the metrics speak the same language as his business.
Impact
Designed, built, and deployed in 11 days as sole developer.
Client approved every milestone on first or second review.
Zero critical bugs reported across 6 milestones of iterative delivery.
206 tests across 27 test files running in under 1 second via Vitest.
22 database migrations managing schema evolution.
Row-Level Security on every Supabase table; no data leaks between roles.
Platform handles the full business lifecycle: lead capture → onboarding → payment → session delivery → analytics.
Timeline
Reflection
The hardest part of Nexus Portal wasn't the velocity. It was the discipline to ship four genuinely separate portals when the easy thing would have been a single admin app with permission flags. Every feature I added had to make sense for four different jobs, and the temptation to cut corners with “admin sees everything” was constant.
What I'd do the same: ship in milestones, each one client-approved, never letting scope drift between them. What I'd do differently: spend an extra day on the data model before the first line of UI. The 22 migrations were mostly the cost of learning the domain in flight.