NanoLink
Link Management SaaSA team-built link-management SaaS with ad-monetized redirects — I owned the authentication system underneath it: local and OAuth login, email verification, password reset, and the JWT token model.
February 2026 · Team Project · ~3 weeks, part-time (Feb–Mar 2026), plus a landing-page pass in May 2026
Project Overview
Overview
NanoLink is a link-management SaaS built by a two-person team as a Final Year Project — a NestJS API and a Next.js 16 frontend in a shared pnpm monorepo. It covers short-link creation with custom domains and expiry rules, multi-tenant workspaces, click analytics on a Tinybird pipeline, a link-in-bio page builder, and an interstitial ad-monetization layer that pays link creators per click. The codebase is large — 24 backend modules, 45 Prisma models — and most of it is my teammate's. My own work was the authentication layer everything else in the app runs on top of, plus the public marketing site.
Problem
A platform with multi-tenant workspaces and a monetization layer where money is attributed per click needs identity to actually hold up — correctly telling a workspace owner from a member, a verified account from an unverified one, and a user who signed up with a password from the same person returning through Google, rather than just gating a dashboard. Getting any of that wrong is a real security or billing bug, not a UX nit. My job was to build that layer end to end: local and OAuth login, email verification, password reset, and the token model everything else authenticates against.
My Contribution
- Built the entire authentication module end-to-end — 14 REST endpoints across 4 controllers; 83% of its ~2,350 lines are still exactly what I wrote, per git blame
- Implemented local (Passport-local) and Google OAuth login, plus a GitHub Passport strategy the team hasn't wired into the frontend yet
- Designed the repository/service split for auth — one AuthRepository as the sole Prisma boundary, with a dedicated service per concern (tokens, OAuth, email verification, password reset)
- Built the OTP email-verification and password-reset flows end-to-end, including the Nodemailer SMTP integration
- Handled OAuth account linking — a Google sign-in matching an existing local account by email links to it instead of creating a duplicate user
- Also built the standalone public marketing site (hero, pricing, comparison table, bento grid) independently of the auth work
Implementation
Key Features
- Local + Google OAuth sign-in via Passport.js strategies
- Access/refresh JWT pair, each signed with its own secret
- 6-digit OTP email verification, rate-limited to 5 resends per 24h
- Token-based password reset with a 1-hour expiry window
- Bitmask-encoded RBAC guard for route-level authorization
- Automatic account linking when an OAuth sign-in matches an existing email
Tech Stack
Frontend
Next.js 16
Backend
NestJSPassport.jsJWTPrismaPostgreSQLZod
Services
Nodemailer
Technical Challenges
Solution
Replaced it with a 6-digit OTP with a 60-second expiry and a bounded resend budget (5 per 24 hours), and explicitly handled re-registration of an email that exists but was never verified.
Result
Shrinks the verification credential's live window from 24 hours to 60 seconds, while still tolerating a mistyped code through resends.
Architecture & Data Flow
Project Walkthrough
Lessons Learned
The auth module has zero test coverage — only the url, user, and domain modules have specs in this codebase. Everything here was verified by hand through manual flows, which is the first gap I'd close if I revisited this code.
Building inside a teammate's fast-moving frontend meant parts of what I shipped — the axios refresh interceptor, the edge middleware — were later substantially rewritten as the app grew; a good reminder that on a team codebase, the code you write is a starting point for someone else, not a finished artifact.
Signing the access and refresh JWT from the exact same payload, just with different secrets, keeps the token logic simple — but it also makes the two tokens structurally interchangeable except for which secret verifies them, which I'd design differently (a distinct token-type claim) if I did it again.