One operating system for fiber engineering — routes, work, money, and access control.
Complex fiber optic engineering projects were being run out of disconnected spreadsheets, document folders, and status conversations. I replaced that with a production Next.js platform built end to end: KMZ/KML route maps, project and segment workflows, Azure Blob document storage, purchase orders, multi-stage invoicing, payments, payroll reserve, role-based access, audit logging, and health/observability tooling.
TypeScript
React
Tailwind
Prisma
SQL Server
Azure
Fragmented Excel can't run a route-driven engineering business.
Fiber optic engineering projects are large, multi-stage, and deeply financial: routes have to be planned and tracked, segments assigned, documents uploaded, work approved, purchase orders consumed, invoices issued, payments recorded, and engineers paid on rules that hinge on those approvals. Running that across spreadsheets means the route plan lives in one place, the money lives in another, and access control is mostly hope.
The goal was to collapse all of that into one authenticated system with a single source of truth — where a project route, its segments, the documents attached to it, the purchase orders it consumes, the invoices it creates, and the payroll it drives are all one relational model. I built it with Next.js 16, React 19, TypeScript, Tailwind 4, Prisma 7 over SQL Server, Better Auth, Azure Blob Storage, Google Maps, Sentry, Vitest, and Playwright.
One relational model under the map and the money.
The platform is a full-stack Next.js application running on Node 24. React, Tailwind 4, and shadcn/Radix components drive the operator UI; Prisma 7's MSSQL adapter talks to a SQL Server schema with 30 modeled domain tables for clients, carriers, projects, segments, documents, purchase orders, invoices, payments, pay periods, engineer payments, review logs, status options, team members, and activity logs. The app leans on server actions, cache tags, revalidation, and serializable transaction retry logic instead of pushing financial state through client-only code.
The mapping side stores KMZ/KML route files and renders them through a Google Maps KML layer, using project-level and segment-level route context. Document handling is not an afterthought: uploads go to Azure Blob Storage under project paths, file contents are validated by extension and magic bytes, sensitive documents are served through short-lived SAS URLs, and blob names/containers are sanitized before delete or access operations. The financial side automates the workflows that used to be manual: purchase-order tracking, multi-stage invoicing, payments, and engineer payroll reserve tied to the work state. The route map shown above is deliberately abstract and illustrative — it represents the structure, not any real geography.
The interesting part is the trust boundary.
The payroll reserve was one of the pieces that justified the whole platform. Engineers are not simply paid because a spreadsheet says work was submitted; payment depends on the state of the segment, invoice, review, and approval workflow. Modeling that meant payroll could not be a standalone calculation — it had to read directly from the same project and segment state that governs invoicing.
That same trust boundary shows up everywhere: Better Auth maps Microsoft identity claims into application roles, proxy middleware applies a nonce-based Content Security Policy, financial fields are filtered by role, every important mutation writes activity history, and Sentry captures errors without turning routine validation misses into noise. Pairing that operational hardening with KMZ-driven route context and financial automation is what turned a spreadsheet sprawl into a single auditable system — and it's the part I'd point to as the real engineering, while the client specifics stay under NDA.