A while back, I built a complete field service management platform for the first time. It worked. But building it taught me as much about what I’d do differently as it taught me about field service software itself.
So I built it again — FieldOS — the way I’d build it now, with everything I picked up the first time around. And this time I tracked every real hour it took, start to finish. Not to hit a deadline. To finally answer a question I’d always guessed at before: how much time does a project like this actually take, and what is that time genuinely worth to the business paying for it?
I do maintenance for a car dealership, an auto parts warehouse, a body shop, and five parts stores in my day job, so I’ve seen firsthand what off-the-shelf field service software costs a business — and how much of it a smaller crew never touches. FieldOS is built so a business only pays for the pieces it actually needs. But the real question underneath this series isn’t what to charge. It’s how to price custom work in a way that’s honest about what the work is worth, without pricing a small business out of getting it built at all. This series is that experiment, told through the build itself.
How the Core System Works
Every field service business needs the same five things to run day to day, no matter what they fix or deliver. This is the part of FieldOS nobody gets to skip — the foundation every add-on plugs into later in this series.
- A Front Door for Every Job: A request comes in, gets logged, and moves through a status list a business defines for itself — not a fixed workflow some software vendor decided everyone needs. A body shop’s process doesn’t look like an HVAC crew’s, so the system shouldn’t force them into the same one.
- Real Parts Tracking: Every part or supply used on a job gets logged against real stock at a real location, and the system flags it automatically the moment something drops below what a crew needs on hand — not after a technician shows up to an empty shelf.
- A Dispatch Board, Not a Spreadsheet: Jobs get assigned to the right technician at a glance, and each tech can see their own schedule without needing access to everyone else’s.
- Getting Paid Without a Bookkeeping Headache: The moment a job is marked done, an invoice drafts itself automatically — parts, notes, and all — routed through a payment processor businesses already trust with millions of transactions a day, not some bolted-on, custom-built checkout page.
Overcoming the Friction
Building the pieces separately is the easy part. Getting them to work correctly together, under real conditions, is where the actual engineering happens.
The Warning That Went Quiet
Low parts triggering an automatic alert only matters if the alert actually fires. While connecting the parts-tracking piece to the job-tracking piece, I found that the low-stock warning had quietly stopped working the moment the two were wired together — invisible when I tested each piece alone, only caught once I ran them as a real pair. The cause was a simple ordering problem: one piece was checking whether the other was ready before the other had actually finished starting up. I fixed the startup order and re-ran the exact scenario that broke it, twice, to be sure.
The Invoice That Forgot Its Own Line Items
During a live test of the automatic billing, I generated a real invoice for parts and labor. The total was correct. The list of what was actually being charged for was blank. A finished invoice with the right number but no explanation of where it came from is worse than no invoice at all — a customer would rightly question it. The bug turned out to be a filtering step that was quietly excluding the exact type of charge line this system uses. One fix, and every future invoice carried its full itemized breakdown.
Five Doors, One That Didn’t Announce Itself
A job can enter this system five different ways — a technician logs it, a customer reports it, a scheduled maintenance check creates it automatically, and so on. While wiring in a piece that keeps a business’s contact list in sync, I found that four of those five doors properly announced “a new job just came in” to the rest of the system. The fifth didn’t, silently, which meant contact records could go stale depending on how a job started. I funneled all five through one shared announcement point so nothing can enter the system again without every other piece hearing about it.
The Business Win
Real time, tracked as I went rather than guessed afterward: roughly three hours, start to finish, to design, build, and verify all five of these pieces working together. Not three weeks. Three hours. By the end of that single focused stretch, the entire core system was live and taking a real job from “reported” all the way through “paid” — confirmed with an actual test checkout, not just a passing code check. A part gets used, stock drops, a technician gets assigned, the job closes out, and an invoice is waiting with the right total and the right explanation of what it’s for.
That’s the floor every FieldOS business runs on. Next in this series: the add-on pieces — the ones a business only pays for if their work actually needs them.