TB Projects
A shared operating system for complex construction projects.
- Status
- Live
- Year
- 2024–26
- Role
- Product engineer — predominantly solo
- Stack
- LaravelReactTypescriptAWS
Overview
Construction projects produce a chain of dependent decisions: what was priced, what the customer approved, what must be ordered, what arrived on site, and which evidence or compliance documents support the work. When each step lives in a different spreadsheet, inbox, or drive, the project record forks at every handoff.
I designed and built TB Projects as a shared operating system for Thomson Brothers. What began as a quoting tool in March 2024 grew into a production platform spanning commercial decisions, purchasing, field activity, compliance, documents, email, and customer approvals—all organised around the same project record.
- 117k
- PHP + TypeScript lines
- 337
- Application routes
- 169
- Database migrations
- 563
- Commits since March 2024
One project, many views
Managers need price and margin; site staff need fast task and delivery context; compliance staff need applications, deadlines, and correspondence; customers need a narrow external view. The core product decision was not to build separate tools for each audience, but focused interfaces over shared data.
The project became the product spine. Quotes, orders, work items, photographs, resources, compliance applications, and linked email conversations retain their own workflows while staying attached to one operational record. Layered permissions, company and customer scopes, sensitivity metadata, and expiring document links enforce those real job boundaries beyond the navigation.
Challenge 1 — making a quote operational
A quote line starts as an estimate, may need a customer decision, becomes orderable after commercial confirmation, then moves through ordered, received, and completed states. Copying it into separate approval and purchasing systems would create competing versions of the truth.
Instead, the line item remains the shared commercial and operational entity. Orderability is derived from explicit domain rules: the quote is deposited, the item is confirmed, its source is office-orderable, and the work is incomplete. Version history preserves how it changed, while customer-safe views omit cost and internal notes. A deposit is therefore not just a label—it is a business transition that can confirm the project, activate workflow stages, and release the right items for purchasing.
Challenge 2 — making field evidence dependable
Photograph upload on a building site is a reliability problem, not a file-input problem. Images are large, mobile browsers are constrained, connections disappear, and silent loss is unacceptable when a photograph is evidence of completed work.
The capture flow resizes and compresses suitable images in the browser, but keeps the original if compression fails, times out, or makes the file larger. A bounded upload queue runs files concurrently, exposes batch progress and partial failures, warns before navigation, and holds a screen wake lock during long uploads. The focused mobile API also accepts client-generated identifiers, making retries idempotent rather than creating duplicate media.
Challenge 3 — useful automation without blind trust
Important project context arrives through email, but automatically attaching a message to the wrong job—or letting a model overwrite project data—would be worse than leaving it in the inbox. I built an asynchronous Microsoft Graph pipeline to fetch incrementally, classify, extract, summarise, and suggest links to projects, applications, clients, and line items.
The same principle shapes compliance follow-up: the system evaluates inactivity and cooldown rules, resolves recipients, assembles the relevant application and thread context, and drafts a response. A person still reviews consequential communication before it is sent, incorrect links can be removed, and attempts are recorded. AI reduces context gathering and first-draft work without silently becoming the system of record.
What the build taught me
Over two years, the work shifted from shipping screens to creating reusable platform capabilities: configurable Kanban stages and triggers, shared resource permissions, queued document generation, secure customer flows, data-reconciliation tools, and production observability. The monolith made that pace possible, but its expanding route and schema surface also demanded stronger internal boundaries and tests around the highest-risk transitions.
The lasting lesson is to model the business event rather than the interface around it. Deposit confirmation, orderability, compliance status, upload failure, and chase eligibility each became explicit rules that could be reused across staff views, customer flows, background jobs, and the mobile API.
