Building a Crew Scheduler for a 15-Person Operation
One of the more interesting builds I have done recently was a crew scheduling tool for a landscaping operation running about 15 employees across multiple crews. The scheduling process had lived inside a shared Google Sheet for years, and it worked well enough when the company was smaller. But as the crew count grew and the job list got longer, the sheet started breaking down in ways that cost real time and created real frustration.
I want to walk through what was breaking and the design choices that fixed it, because this build shows how a custom tool reaches problems that off-the-shelf software either cannot touch or prices out of range for a business this size.
The problem
The scheduling sheet was a weekly grid. Days across the top, employee names down the side, job assignments typed into each cell. The operations manager updated it every Sunday night and shared it with crew leads Monday morning. On paper, this should work fine.
In practice, it created several recurring problems. Scheduling conflicts stayed invisible until someone showed up at the wrong site. The manager matched skills from memory, because he knew which employees were certified for specific equipment, but that knowledge lived in his head and not in the file. When someone called in sick, rescheduling meant scanning every cell by hand to find coverage, usually under time pressure.
The company had looked at commercial scheduling platforms and found the pricing prohibitive for a 15-person operation. Most field service management tools are built for larger companies and charge per user per month, which adds up fast when the margins in landscaping are already tight. They needed something that did the job without the recurring cost.
The constraints
The tool had to run in a browser. No app to install, no software to learn. Crew leads check the schedule on their phones at 6 a.m., and if the tool did not load instantly and read clearly on a small screen, it would not get used. It had to work without a subscription. The client wanted to own the tool outright, not rent access to it. That meant building something self-contained that could be hosted cheaply or even run from a static file. And it had to be simple enough that the operations manager could update it without technical knowledge. The person building the schedule every week is not a developer. They drag or type, and the tool handles the logic.
The design decisions
The first decision was to build constraint matching into the assignment logic. Instead of relying on the manager's memory for who can run what equipment, the tool stores employee certifications and skill tags. When a job requires a specific certification, the tool filters the available crew down to the people who qualify. That eliminated the most common scheduling errors right away.
The second decision was to flag conflicts automatically. If an employee is assigned to two jobs on the same day, or if a job does not have enough crew assigned, the tool surfaces a warning before the schedule is finalized. In the Google Sheet, those conflicts only became visible when someone caught them in the field.
The third was to make the weekly view the default. The manager thinks in weeks, not days. The tool opens to the current week, shows every crew and assignment at a glance, and lets the manager build next week by copying the current week and adjusting. That mirrors how they already worked in the spreadsheet, just with guard rails.
What it replaced
The Google Sheet took about 90 minutes to build each week, counting the time spent cross-referencing skill requirements and texting crew leads with each change. The scheduling tool cut that to roughly 30 minutes, and the schedule it produces is more reliable because the constraint logic catches errors the manual process missed.
The tool also ended the Monday morning confusion that happened when crew leads got an updated schedule after they had already started their day. The browser-based format means everyone looks at the same version in real time, and any late change is visible immediately.
You can try a working demo here. It shows the interface and how the constraint matching plays out in the weekly view.
The build-versus-buy math
A commercial field service scheduling platform for 15 users typically runs $50 to $150 per user per month, depending on the vendor and the feature set. At the low end, that is $750 a month, or $9,000 a year. Over two years, the company would spend $18,000 on software that does far more than they need, most of which they would never use.
The custom build cost a fraction of that, and the company owns it outright, with no monthly bill and no per-user charge. If they grow to 25 employees, the tool scales with them at no added cost. If they want to change how the constraint logic works, they request an update instead of filing a feature request with a software company and waiting.
This is not the right approach for every business or every problem. But for a 15-person operation with a specific scheduling workflow and a clear set of constraints, a custom tool built to their process was cheaper and more useful than anything on the market at their price point.
