Featured engineering case study
A multi-tenant field-operations workspace that turns customer requests into scheduled, evidence-backed jobs, with human approval before any AI-proposed change.
Product challenge
Field-service work moves from customer intake to scheduling, assignment, on-site evidence, and final review. OpsFlow brings those hand-offs into one tenant-scoped workflow so the current owner, status, and operational history stay visible.
The harder engineering constraint was AI safety: an AI suggestion can be useful, but it should never bypass tenancy, permissions, or lifecycle rules. OpsFlow therefore treats AI output as a proposal that an authorised person must review before it can change operational data.
Job lifecycle
Owner and Manager roles plan and review; Staff completes the work and attaches evidence.
New
Scheduled
In progress
Pending review
Completed
My ownership
Technical foundation
Clear application boundaries without the operational cost of splitting an evolving portfolio product into distributed services.
Product UI
React, TypeScript, Tailwind CSS, Zustand, TanStack Query, and Zod.
Application API
Tenant-aware middleware, RBAC, JWT sessions, and domain services.
Persistence
Tenant-scoped operational data, audit activity, and persisted AI proposals.
Delivery
Nginx and HTTPS on EC2, Amazon RDS, plus GitHub Actions CI and deployment.
Decisions and trade-offs
The value of the project is not just what it does, but why its boundaries were designed this way.
Keep the web app and API modular, but deploy them as one product while the domain and traffic are still evolving.
Trade-off: This simplifies transactions, local development, testing, and delivery; modules still scale and deploy together.
Business entities carry a tenant ID, while service queries combine tenant filtering with role checks.
Trade-off: The invariant must be preserved in every new query, so PostgreSQL integration and security tests exercise cross-tenant denial.
AI-generated changes are stored as pending proposals instead of writing directly to operational records.
Trade-off: Confirmation adds a step, but it creates a review boundary where tenant, role, state, and domain rules are checked again.
Engineering evidence
The source, boundary tests, end-to-end journeys, and delivery workflow make the engineering claims below directly inspectable.
PostgreSQL-backed integration and security tests cover tenant filtering and cross-tenant denial paths.
A Playwright journey follows Owner creation, Staff execution, and Manager review through the job lifecycle.
Proposal end-to-end tests and deterministic evaluation cases cover routing, conflicts, and confirmation safety.
The public demo is delivered through a CI-gated GitHub Actions workflow to a deployed EC2 and RDS topology.
Explore the product