OpsPilot

OpsPilot connects the full loop so a customer request can become a scheduled job, executed work, an invoice, a payment, and a follow-up — inside one multi-tenant system.

1. Customer→
2. Request→
3. Job→
4. Schedule→
5. Technician→
6. Work→
7. Completion→
8. Invoice→
9. Payment→
10. Follow-up

Feature claims below are grounded in the current NestJS modules, Drizzle schema, and Next.js surfaces. Product vision items that are not shipped yet are listed separately.

Implemented

• Authentication

  Email/password auth via Better Auth on the NestJS API, with login and signup UI in the Next.js app.

• Authorization

  Organization-scoped membership with OWNER, ADMIN, DISPATCHER, and TECHNICIAN roles enforced in API services.

• Organizations & team invites

  Multi-tenant organizations, member management, and invitation accept flow.

• Customers

  CRUD APIs for organization-owned customer records (contact, address, status).

• Requests

  Service-request intake with priority, source, preferred timing, and review statuses.

• Jobs

  Jobs created from accepted requests, with status lifecycle from draft through completion or cancellation.

• Scheduling

  Schedule and reschedule endpoints set scheduled windows and location on jobs (API-first; no calendar UI yet).

• Technicians

  Technician profiles and job assignment / reassignment with overlap checks.

• Work & completion

  Progress updates, notes, photo uploads (local disk storage), activity timeline, and job completion summaries.

• Invoices

  Invoice creation from completed work, line items, send, and void flows.

• Payments

  Payment recording against invoices, including refund handling (online gateway success not accepted from the client alone).

• Follow-ups

  Feedback and maintenance-reminder follow-ups with due dates and status tracking.

• Dashboard shell

  Authenticated dashboard layout, organization switching, role-aware sidebar, and placeholder operational overview.

• Automation, analytics & audit

  Rule-based automation engine, analytics endpoints, customer notifications, and audit logging APIs.

Planned / still building

• Full CRUD screens for jobs, customers, requests, invoices, and related modules (sidebar routes exist; pages are still being built)
• Calendar / dispatch board UI for scheduling
• Google OAuth (button present, marked coming soon)
• Payment gateway–backed online checkout
• AI request intake, AI scheduling assistance, and operations assistant from the product vision
• Channels such as WhatsApp / SMS automation beyond the current notification model

• Turborepo + Bun

  Workspace orchestration for apps/* and packages/* with cached lint, typecheck, test, and build pipelines.

• Next.js web

  App Router frontend with Tailwind CSS and shadcn/ui. Auth UI, onboarding, invitations, and dashboard shell are in place.

• NestJS API

  Modular Nest controllers/services for customers, service requests, jobs, technicians, invoices, payments, notifications, automation, analytics, and audit.

• PostgreSQL + Drizzle ORM

  Hosted Supabase PostgreSQL with Drizzle schemas, RLS-enabled tables, and committed SQL migrations. The web app does not connect to the database.

• Authentication

  Better Auth with Drizzle adapter; Nest integration via @thallesp/nestjs-better-auth session guards.

• Authorization

  x-organization-id scoped requests plus membership/role checks in services (managers vs technicians, etc.).

• APIs & docs

  REST endpoints with class-validator DTOs and Swagger documentation for the operational surface area.

• Background work & storage

  In-process automation scheduler (no BullMQ). Job photos use a swappable FileStorage abstraction with local disk today.

OpsPilot is a Bun + Turborepo workspace. Applications own runtime concerns; packages own shared UI and tooling. That split keeps the API and web app independently deployable while sharing types, lint rules, and components as the product scales.

• apps/web

  Next.js App Router UI — auth, onboarding, dashboard shell, design system

• apps/api

  NestJS HTTP API — domain modules, Drizzle schema/migrations, Better Auth, Swagger

• packages/ui

  Shared React primitives consumed by the web app

• packages/eslint-config

  Shared ESLint configuration for web packages

• packages/typescript-config

  Shared TypeScript bases across the workspace

The Drizzle schema models a multi-tenant operational graph. Users authenticate, belong to organizations, and operate on customers through service requests, jobs, assignments, invoices, payments, and follow-ups. Supporting tables cover notes, photos, activity, notifications, automation, and audit logs.

1. User→
2. Organization→
3. Customer→
4. Service Request→
5. Job→
6. Schedule→
7. Technician→
8. Work→
9. Completion→
10. Invoice→
11. Payment→
12. Follow-up

Schedule is represented on the job (scheduledStart / scheduledEnd). Technicians connect through job_assignment. Work artifacts live in notes, photos, and activity rows. There is no separate fictional entity invented for this page.

• Monorepo

  Keeps the Nest API and Next UI in one repo so domain types, tooling, and shared UI evolve together as the product grows.

• NestJS backend

  Module boundaries map cleanly onto operational domains (jobs, invoices, automation) with DI-friendly services and tested controllers.

• PostgreSQL

  Relational model fits multi-tenant organizations, jobs, assignments, invoices, and payments with strong integrity constraints.

• Drizzle ORM

  TypeScript-first schema colocated with the API, SQL migrations, and RLS-aware table definitions — the active ORM in the codebase.

• API-first domain workflow

  Core operational loop is implemented and authorized in the API first; the web UI is catching up with auth/shell screens before full CRUD pages.

• Better Auth + org roles

  Session auth at the edge of the API, then organization membership and role checks for business actions.

• Validation & testing

  DTO validation with class-validator; API unit and e2e tests with Jest/Supertest; CI lint/typecheck/test/build via Turborepo and GitHub Actions.

• Scalability posture

  Tenant isolation by organizationId, indexed operational tables, swappable file storage, and automation designed around persisted executions rather than fire-and-forget side effects.

Links point at existing files in the OpsPilot repository. There is no separate fabricated PRD, database, or API design doc beyond what is checked in.

• Product Requirements / Features

  OPSPILOT_FEATURES.md — product vision, modules, and operational lifecycle

• Architecture

  docs/ARCHITECTURE.md — monorepo layout and stack (docs may lag the Drizzle migration noted in code)

• Repository README

  README.md — setup, environment, quality checks

• Automation Engine Spec

  docs/specs/0001-automation-engine — triggers, actions, and verification notes

• Analytics & Reports Spec

  docs/specs/0002-analytics-reports

• Audit Logging Spec

  docs/specs/0003-audit-logging

• Domain modeling

  Field service is a lifecycle, not a flat CRUD list — requests, jobs, assignments, invoices, and follow-ups need explicit relationships.

• Workflow-driven design

  Status transitions and schedule/assign/complete endpoints encode the real operating loop instead of generic update handlers alone.

• API architecture

  Modular Nest services with organization scoping keep multi-tenant boundaries enforceable at every write path.

• Authn / authz

  Session authentication is necessary but not sufficient — membership and role checks decide who can schedule, invoice, or act as a technician.

• Database design

  Enums, foreign keys, unique job-per-request constraints, and indexes on status/schedule fields mirror how dispatchers actually query work.

• Monorepo architecture

  Shared tooling and packages reduce friction as the web UI and API ship on different cadences toward the same product.

• Reusable frontend architecture

  Auth layout, org providers, design-system primitives, and a role-aware shell create a stable base for upcoming operational screens.

• Product thinking

  Building the operational loop end-to-end in the API first makes the UI work concrete — screens attach to real workflows, not invented dashboards.

From request to payment, still shipping.

Explore the repository for the live schema and API surface, or return to selected work on the portfolio.