Building Work Log Pro: A SaaS Time Tracker with Next.js and MongoDB
How I built a full-featured SaaS work tracking platform from scratch — architecture decisions, the 80+ REST API endpoints, API token system, AI insights integration, and the CI/CD pipeline that keeps it reliable.
Building Work Log Pro: A SaaS Time Tracker with Next.js and MongoDB
Work Log Pro is the most ambitious project I have shipped — a full SaaS work-tracking platform with
80+ REST API endpoints, AI-powered insights, JWT authentication, API token management, team management,
billing, and an admin dashboard. Here is an honest account of how it was built, what went wrong, and
what I would do differently.
Why Build a Work Tracker?
The itch came from using half a dozen existing tools and finding all of them wrong in different ways.
Some were too simple (just timers). Some were too complex (project management suites where time tracking
was a buried afterthought). None surfaced useful insight from the data they collected. I wanted a tool
that felt lightweight to use but gave you real intelligence about where your time goes.
Architecture Decisions
Next.js 15 with App Router for both the frontend and the API layer. The App Router's server
components let me fetch data directly in page components without client-side loading states for the
initial render. API routes handle the REST endpoints — no separate Express server needed.
MongoDB with Mongoose for persistence. Work log data is document-shaped and write-heavy.
MongoDB's flexible schema let me iterate on the data model quickly in the early stages. Mongoose
adds schema validation, TypeScript types, and the population mechanism I use for joining user
and project data.
JWT authentication with two token types: short-lived session JWTs (1 hour) stored in
httpOnly cookies, and long-lived API tokens for programmatic access. API tokens use a wlp_
prefix and are stored as SHA-256 hashes — the raw token is shown only once at creation,
exactly like GitHub personal access tokens.
OpenAI API for AI insights, integrated lazily to avoid build-time crashes in CI environments
where the API key is not set.
Service Layer Architecture
With 80+ endpoints across 15 resource groups, keeping the codebase organised required discipline.I settled on a service layer pattern: