Sheled
Internal operations system for a civil engineering firm — a custom CRM with an AI layer on top.
Overview
Sheled is the internal operations system for a civil engineering firm that runs dozens of active construction projects at once.
The first phase mapped the firm’s entities — projects, equipment, vehicles, insurance, workers, and the rest — into a single source of truth. The second layers AI on top: a chat assistant that reads and writes against the data, and document-to-entity extraction.
Built end-to-end for my family’s civil engineering firm — which means full access to how the operation actually runs. In daily production use by office staff.
The problem
A civil engineering firm at this scale doesn’t run on one system. It runs on a dozen of them — a project tracker in Excel, an equipment log in a different Excel, a folder of scanned insurance PDFs, and the office manager’s memory for everything the spreadsheets miss.
That works until it doesn’t. Running a firm at this scale through scattered files is slow, repetitive work. The office day disappears into reconciliation — pulling numbers from one spreadsheet to compare against another, chasing the current version of the worker list across three inboxes, copying the same record into yet another file.
When everyone maintains their own copy of the same data, the versions drift apart by default. The gap between the firm’s scale and the tooling that supports it gets paid for in time and accuracy.
What I built
A web app on React, Express, and Supabase, built in two phases.
Phase 1 — the operational CRM. Map the firm’s entities and workflows into a single source of truth. The operational backbone is a set of connected modules:
- Projects — every active construction job, with its site, timeline, assigned crew, and the equipment currently on it.
- Equipment — heavy machinery and tools as a tracked registry, with assignment history showing which project each unit has been on and when.
- Vehicles — the fleet, with registration, insurance, and maintenance windows surfaced before they lapse.
- Workers — the people on site, with their certifications, current assignments, and coverage status visible from one row.
- Guarantees — bonded obligations and warranty terms tied to projects and accounts, with expirations and renewals surfaced like insurance instead of scattered paperwork.
These are the load-bearing ones. The schema goes further — accounts, subcontractors, and the rest of the firm’s record-keeping live in the same system, modeled to match how the team already thinks about them.
The modules aren’t independent — entities link to one another across the system, mirroring how they relate in the firm’s actual work.
On top sits the platform layer: authentication, role-based access control so different staff see different surfaces, and an alert system that watches time-bound data and surfaces what needs attention before it lapses.
Phase 2 — the AI layer. With the entities mapped, the second phase is making them faster to work with. Two pieces are live:
- A chat assistant with read and write access to the firm’s data. Staff ask questions in natural language and can run CRUD operations through conversation instead of clicking through forms.
- Document-to-entity extraction. Instead of manually typing data from a document into a new entity, staff drop the file in and the AI extracts the fields and creates the entity directly.
The AI layer’s job is to shorten the path between something the firm needs to record and that thing being a row in the database — without forcing staff to learn the schema.
Stack
- Frontend
- reactvitetypescript
- Backend
- nodeexpresstypescriptsupabase
- Tooling
- aws bedrockresendsentryposthog