Greeen Building By Design, California, USA
Construction Project Management Platform
A project, time and billing system for a design-build studio: phases, tasks, file notes, tracked hours and billable items that assemble themselves into an invoice.
- Status
- Completed
- Industry
- Construction & Design
- Year
- 2024
- Categories
- Web Applications, Automation, Business Systems
Building the smallest project tool that could still produce the invoice
A custom project, time and materials tracker for a design-build studio, scoped down to what the team would actually use and ending at a generated invoice.
A design-build studio running several jobs at once has a bookkeeping problem disguised as a project management problem. Who worked on what, for how long, at which rate, using which materials — and can any of that be turned into an invoice without someone rebuilding it by hand from notes and memory?
The off-the-shelf tools they had tried failed in the usual two directions. Either the tool did not model how a build actually runs — phases with payment schedules, materials consumed per task — or it did everything, at a price and a complexity the team would not absorb.
What we built
We started narrow and grew it: projects and project types, then tasks with dated notes and file attachments, then time tracking per person per task, then a catalogue of billable items, then clients, users and company details — and finally the piece that made the rest pay off, invoice generation that assembles a phase payment, the materials used and the billable hours into one printable document.
- Invoice source
- Derived, not stored
- Time tracking
- Per user, per task
- Project types & phases
- Client-editable
The problem
Tracking several simultaneous builds across a team is tedious in a specific way: the data that matters for billing is generated in the field, in small pieces, by people who are not thinking about billing. Hours worked, materials consumed, a photo of a wall before it was closed up.
By the time an invoice is due, that information is spread across notebooks, texts and memory, and someone spends an evening reassembling it — badly, because anything forgotten is simply never billed.
Generic project management tools did not fit. They model tickets and sprints, not phases with payment schedules and a materials list, and the ones that could be bent into shape carried far more product than the team wanted to learn.
Requirements
- Track multiple concurrent projects, each with a type and a current phase
- Record tasks against a project with dates, free-text notes and file attachments
- Log time per user, per task, with a duration and an hourly rate
- Maintain a catalogue of billable items with unit costs
- Keep clients, team members and company details in the same system
- Generate an invoice from a phase, its items and its billable hours
- Stay small enough that the team would actually use it
The solution
The design decision that shaped everything else was to make the invoice the endpoint of the data model rather than a separate document. A phase payment, the items consumed and the hours logged are not gathered for the invoice — the invoice is a view over records that already exist because the team captured them while working.
The project detail screen is deliberately one screen. Tasks, notes, attachments and the time-tracking table are stacked in a single panel with inline entry rows, so logging an hour against a task is one interaction rather than a navigation.
Notes and files hang off individual tasks rather than the project, which is what makes them findable later. "The photo of the piping" is attached to the piping task, not buried in a project-wide folder.
Billable items are a maintained catalogue rather than free text. A line on an invoice points at an item definition with a unit cost, so the same material is priced the same way twice.
Project types and phases are data the studio edits themselves, because the vocabulary of a build — as-built, design AD, landscaping — belongs to the client, not to us.
Architecture
A straightforward Laravel application on MySQL, with jQuery and DataTables handling the table interactions and inline editing. No single-page front end, because the interaction model is forms and tables and a page load is not the bottleneck.
Invoices are rendered server-side to PDF from the same records the application already holds. There is no invoice document stored as a blob of copied values — regenerate it and you get the current truth.
Attachments are stored outside the database against the task they belong to.
Implementation
We built it progressively, in the order the client could use it. Projects and tasks first, which was immediately better than notebooks; then time tracking, which was the piece that made billing possible; then items and invoicing.
That order mattered. Each stage was usable on its own, so the studio was working in the system months before the invoicing existed, and the invoicing was designed against real recorded data rather than an assumption about what people would enter.
Tables throughout use search, pagination and column visibility, and export to CSV. The studio's own accountant does not need a login to get numbers out.
Results
The studio runs its projects, team, tracked hours and billing in the system, and the invoice that used to be reassembled by hand is generated from records captured during the work.
We have not published a time-saved figure because we did not measure the manual process it replaced, and a number we did not measure is not a result.
What we learned
Starting simple and growing was not a compromise, it was the reason the tool fits. Every feature was added in response to the team hitting its absence in real work, which is a much better filter than a requirements workshop.
Making the invoice a derived view rather than a document removed an entire class of reconciliation bugs. There is no second copy of the numbers to drift.
Letting the client own their own vocabulary — project types, phases — stopped a steady drip of change requests that would otherwise have needed a developer each time.
Gallery
