Case study
An employee-owned mechanical contractor with about 200 field staff across the US Pacific Northwest ran job costing, change orders and equipment scheduling in shared spreadsheets. We replaced them with one web application the whole company works in.
Named only with client approval Figures marked are illustrative Reply within one business day
Illustrative product interface — not client data.
OlDevs built a web application on Laravel and PostgreSQL for an employee-owned mechanical contractor, with roles for field supervisors, project managers, controllers and owners, so approvals follow a defined route rather than a group chat.Crew and equipment scheduling share one calendar with conflict detection, and reporting reads the live records instead of an exported copy. Field staff use it in a phone browser, with nothing to install. The work retired 31 spreadsheets, put a first release into production use in 6 wk, and cut the time to price a change order by 63%.
Key facts
The challenge
Job costing, change orders, equipment scheduling and time approvals all lived in shared spreadsheets that three people knew how to repair. Two crews could be booked on the same excavator, and a change order could sit in an inbox for a week before anyone priced it. Growth had made the workarounds more expensive than the work itself.
The costing and scheduling workbooks were understood by only three staff. A holiday or a resignation was an operational risk, and nobody else could safely change a column without breaking a report somewhere downstream.
Crew scheduling and equipment scheduling lived in separate sheets with no check between them, so two crews could be assigned the same excavator on the same morning. The conflict usually surfaced on site, once one of the crews had already travelled.
A change raised in the field was emailed, forwarded and sometimes forgotten, so pricing could wait a week. Work carried on in the meantime, which meant the company was either absorbing the cost or arguing about it with the client much later.
Every report began with somebody exporting and reconciling sheets, so the numbers were always a few days old and never quite matched between departments. Owners were making decisions on a picture that had already changed underneath them.
What we built
OlDevs built a web application on Laravel and PostgreSQL with roles for field supervisors, project managers, controllers and owners, so approvals follow a defined route rather than a group chat. Crew and equipment scheduling share one calendar with conflict detection, and reporting reads the live records instead of an exported copy. Field staff use it in a phone browser, with nothing to install.
Field supervisors, project managers, controllers and owners each see the queue that belongs to them, and time, cost and change approvals follow a defined route with a visible status. Nothing depends on somebody noticing a message in a group chat.
Crews and equipment are scheduled on the same calendar, and the application refuses an assignment that would put two crews on one asset, showing the booking it clashes with. The conflict surfaces while the schedule is still being made rather than on site.
Hours, costs and approved changes post against the job as they happen, and reports read those records directly. Owners and controllers look at the same numbers on the same day instead of reconciling two different exports.
Field staff open the application in the browser on the phone they already carry, with nothing to install and no app store account to create. Time entry, change requests and approvals are short forms built for a small screen rather than a desk.
Process
Ride along with the work
We sat with supervisors, project managers and controllers, walked through the live spreadsheets, and traced how a change order actually moved from a job site to an invoice.
Model the data first
Jobs, cost codes, crews, equipment, changes and approvals were modelled in PostgreSQL before any screens, so the reports the owners needed were possible by design.
Ship a first release fast
Rather than a year of building in the dark, a first release went into production use in 6 wk, starting with the workflow that hurt most and growing from real daily use.
Add modules with a demo every week
Scheduling, job costing, time approvals and reporting were added in sequence, with a working demo every week so the team could redirect the build before anything set.
Retire the spreadsheets deliberately
Each workbook was replaced, reconciled against the application for a period, then retired on a date the team agreed, until all 31 of them were out of daily use.
Stack
Application
Data
Front end
Reporting and documents
Delivery
31
Spreadsheets retired
6 wk
First release in production use
−63%
Time to price a change order
Outcomes
31 spreadsheets were retired, so job costing, scheduling and approvals no longer depend on the three people who knew how to repair a broken workbook.
The first release was in production use in 6 wk, which meant the team was already working differently while the rest of the application was still being built.
Time to price a change order fell 63% once requests were raised in the application, routed to a named approver and visible to everyone waiting on them.
Crews and assets share one calendar with conflict detection, so a clash is caught when it is booked rather than on the morning two crews arrive for the same excavator.
In their words
Change orders get priced the same week they are raised, and I have stopped hearing about double booked equipment.
Operations director, employee-owned mechanical contractor
Construction and trades
FAQ
That was the main design constraint. The application runs in the browser on the phone they already carry, with nothing to install and no app store account to set up. Time entry, change requests and approvals use large targets and short forms, and supervisors tried them in a working demo every week while the build was still open to change.
In stages. We started with the workflow causing the most pain and had a first release in production use in 6 wk, then added scheduling, costing, approvals and reporting module by module. Each workbook ran alongside the application until the numbers reconciled, and was then retired on an agreed date.
Crews and equipment sit on one calendar backed by one database, and the application checks availability the moment an assignment is saved. A clash is refused and the conflicting booking is shown, so the scheduler resolves it there instead of discovering it in the field.
Reports read the live records rather than an exported copy, so job costing, approved changes and hours all reflect what was entered today. We modelled the data around the questions controllers and owners asked in the first workshops, which is why those reports exist without a nightly reconciliation.
Yes. You own all code, designs, accounts and IP. It is a standard Laravel and PostgreSQL application with migrations, tests and documentation in your own repository, so any competent Laravel team can pick it up. We stay involved for as long as that is useful to you, not because you are locked in.
Let’s connect
Tell us what is not working. We’ll reply within one business day with how we would approach it and a tailored quote.