One system for fiber engineering — maps, money, and payroll in one place.
Complex fiber optic engineering projects were being run out of a pile of disconnected spreadsheets. I replaced that with a single full-stack platform built end to end solo — KMZ route mapping, purchase-order tracking, multi-stage invoicing, and an engineer payroll reserve model that all share one source of truth. This is an architecture write-up: the project is under NDA, so there's no real geography, no client names, and no production screenshots here.
React 
Prisma 
SQL Server 
Azure 
Fragmented Excel can't run a fiber engineering project.
Fiber optic engineering projects are large, multi-stage, and deeply financial: routes have to be planned and tracked, materials purchased against orders, work invoiced in stages as it's approved, and engineers paid on terms that hinge on those approvals. Running that across a stack of disconnected spreadsheets means the route plan lives in one place, the money lives in another, and nobody can trust that the two agree.
The goal was to collapse all of that into one system with a single source of truth — where a route, the purchase orders against it, the invoices it generates, and the payroll it drives are all the same underlying data, not four copies that drift apart. I built it end to end solo with Next.js, React, Prisma, SQL Server, and shadcn/ui.
One data model under the map and the money.
The platform is a full-stack Next.js application. React and shadcn/ui drive the operator-facing UI; Prisma is the data layer over a SQL Server database that holds the canonical model — projects, routes, purchase orders, invoices, and payroll records — with the relationships between them enforced in the schema rather than reconstructed by hand in a spreadsheet. It runs on Azure.
The mapping side parses KMZ files to bring fiber routes into the system, then renders them as an interactive map view. That isn't decoration — route geometry is the planning and execution backbone, so the same imported route is what purchase orders, invoicing stages, and payroll all attach to. The financial side automates the workflows that used to be manual: purchase-order tracking, multi-stage invoicing as work is approved, and engineer payroll with an 80/20 reserve model tied to permit approvals. Because everything references one model, a permit approval can ripple into the invoice and payroll state without a human re-keying it across files. The route map shown above is deliberately abstract and illustrative — it represents the structure, not any real geography.
Tying payroll to approvals, not to optimism.
The payroll reserve was the piece that justified the whole platform. Engineers aren't simply paid on submission — an 80/20 reserve model holds back a portion of pay until the work clears the gate that actually matters in fiber engineering: permit approval. Modeling that meant payroll could not be a standalone calculation; it had to read directly from the same approval state that governs invoicing.
So the architecture treats permit approval as a shared event rather than a status someone copies between sheets. When an approval lands, the multi-stage invoice it unlocks and the reserved payroll it releases are derived from one consistent record. Pairing that financial automation with KMZ-driven route mapping is what turned a spreadsheet sprawl into a single auditable system — and it's the part I'd point to as the real engineering, since the code and the client specifics stay under NDA.