Granite Ridge Civil
Studio Demo • Heavy Civil Ops Platform • 2026
The job-cost spine for a heavy-civil general engineering contractor: estimate versus actual by cost code, field time with location capture, and six roles scoped in the database. Shown as a working, seed-driven demo.
The organization
Granite Ridge Civil is a studio demonstration build: the operating platform for a fictional heavy-civil general engineering contractor in Northern California. Public-works contractors live and die by margin visibility, and the platforms they rent are shaped for much larger companies. I designed the platform a fifteen-person GC actually needs, job costing, field capture, and access control as one system, and seeded it like a real book of business.
The challenge
A contractor's real product is a margin. Labor, equipment, trucking, rentals, materials, and subs all burn against an estimate, and if field time does not land on a cost code the day it happens, the job-cost number is fiction. The build had to keep that number true: every hour and receipt posting to a job and a cost code, six roles from owner to client each seeing exactly what their database policy allows, and a clock-in that works the same for the crew and the third-party haul driver.
My approach
The cost code is the atom
Every entry, whether labor, equipment, trucking, rental, material, or subcontract, posts to a job and a cost code. Estimate versus actual reads by code, by class, and by job, so an overrun surfaces mid-job instead of at closeout.
Field capture without an app store
Enter an email, get a code, pick a job, pick a cost code. The same two-tap clock-in serves the crew, third-party haul drivers, rental operators, and subs, geo-stamped and safe to use offline.
Access enforced in Postgres
Six roles scoped by Row-Level Security and column-level grants rather than the interface. The Access module shows the actual policy shapes, and the restricted cells show what each role's policy withholds.
Worker PII behind its own wall
Certified-payroll data is captured, but tax IDs live in a separate PII table whose key is held outside Postgres, because RLS gates rows, not columns.
Seeded like a real book of business
Five public-works and private jobs with fabricated clients, crews, receipts, and punches, all flowing through the same calculations a live tenant would run.
Inside the build
What we built
- An owner's dashboard: backlog, cost to date, blended margin, and estimate versus actual on every job
- A cost-code breakdown that flags the paving overrun at 62% complete instead of at closeout
- A four-step field clock-in: email code sign-in, job, cost code, geo-stamped punch
- Receipt capture where a model proposes the coding and a human confirms before anything posts
- One crew surface spanning employees, third-party drivers, rented units, and subs
- An Access module showing the live RLS policy shape for every role
- A role switcher: owner, project manager, foreman, operator, bookkeeper, and client each see a different platform
The outcome
This is the deepest architecture proof on the page: a platform where the cost model, the field workflow, and the security model were designed as one system, and where the access story is told in actual Postgres policy shapes rather than a marketing diagram. Everything shown runs on fabricated seed data behind a fictional brand; the architecture and design are the real work product.