Problem
Many businesses handle requests through email, WhatsApp, spreadsheets, and manual follow-ups. This creates lost information, poor visibility, slow response times, and no central reporting.
<- Back to Demo Lab
Full-Stack TypeScript Demo
ClientOps Hub
A full-stack TypeScript business operations platform for managing client service requests, internal workflows, dashboard reporting, content updates, and activity tracking.
Demo credentials are provided in my CV or cover letter so reviewers can explore the role-based workflow.
User roles
CLIENTADMINAGENT
Product preview
Dashboard and request workflow
A quick visual snapshot of the kind of operational interface the demo is built around: metrics, request cards, assignment, notes, and activity history.
Solution
ClientOps Hub gives the business a structured request intake system, protected demo access, role-based request visibility, status tracking, dashboard metrics, and activity logs backed by a PostgreSQL database.
Product workflow
Key Features
The demo is structured around the daily work a business needs to manage: intake, visibility, follow-up, and traceability.
Authenticated request intake
Demo users can sign in and create structured requests with priority, request type, and message details. Client users are locked to their own company identity.
Admin dashboard
Admin and agent users can view live request metrics, open requests, high-priority items, and operational summaries from the database.
Request management
Staff can search, filter, inspect request details, assign ownership, add internal notes, and update workflow statuses while client users stay in a read-only status view.
Activity logging
Request creation, internal note creation, and status changes are recorded with timestamps and actors so the system has a clear operational history.
Implementation stack
Tech Stack
These are the tools and platform decisions behind the build, grouped by where they fit in the system.
Frontend
ReactNext.js App RouterTypeScriptResponsive UI
Backend
Next.js Route HandlersNode.jsAuth.jsAPI Design
Database
AWS PostgreSQLPrisma ORMRelational DataSeed Data
Engineering
ESLintTypeScript CheckingPassword HashingRBAC
Engineering decisions
Build thinking
This section explains the choices I would discuss in an interview: architecture, data model, APIs, security, delivery, and the trade-offs behind the MVP.
Architecture
The system is built as a Next.js App Router application with protected demo routes, server-side request handling, Auth.js sessions, and a Prisma database layer behind the workflow.
- Protected demo pages require users to sign in before accessing the workflow.
- Admin and agent users can manage request progress across all companies.
- Client users only see requests connected to their own company.
- Route handlers handle request creation, internal notes, status updates, RBAC checks, and activity logging.
Database model
The data model is centered on client requests, assignment ownership, demo users, internal notes, and request activity records stored in AWS PostgreSQL through Prisma.
- One request stores client identity, company, request type, priority, status, and summary.
- One request can store the assigned owner and owner role.
- One request can have many activity log entries.
- One request can have many internal notes for admin and agent users.
- Demo users store name, email, hashed password, role, and optional company.
- Seed data creates realistic demo requests and role-based demo accounts.
API design
The backend uses typed route handlers for request listing, request creation, assignment updates, internal notes, and status updates with server-side authorization checks.
- Request listing filters by company when the signed-in user is a client.
- Request creation validates allowed request types and priorities.
- Client-created requests use trusted session identity for name, email, and company.
- Assignment updates are restricted to admin and agent users.
- Internal note creation is restricted to admin and agent users.
- Status updates are restricted to admin and agent users.
Authentication approach
The demo uses Auth.js credentials login, seeded users, bcrypt password hashing, protected routes, and role-based access control.
- Unauthenticated users are redirected to the demo login page.
- Roles separate admin, agent, and client permissions.
- Client users cannot spoof name, email, or company values through the browser.
- Status update endpoints reject unauthenticated users and forbidden roles.
CI/CD pipeline
The project includes a GitHub Actions workflow that checks the application before deployment.
- Install dependencies with npm ci.
- Run linting.
- Run the Vitest test suite.
- Run the Next.js production build.
- Use CI-only placeholder environment values so secrets stay out of the repository.
Testing approach
Testing starts with business logic that can be verified without a browser or database, then can expand into API and workflow coverage.
- Vitest is configured with the same path alias style used by the app.
- Filtering tests check search across request fields.
- Filtering tests check status filtering.
- Filtering tests check combined search and status behavior.
Trade-offs
The demo focuses on the highest-signal workflow for interview review: authentication, request management, role-based access, and persistent data.
- The demo uses seeded accounts so reviewers can test roles quickly.
- The current workflow does not include file uploads or external customer messaging yet.
- Dashboard metrics are intentionally simple and readable.
- The database contains demo data only, not client data.
What I would improve next
The next improvements focus on deeper validation coverage, richer records, and clearer client communication.
- Add focused tests for request creation and RBAC behavior.
- Add file/document metadata to support richer client request records.
- Add customer-facing update messages for clearer client communication.