DEV Community

Scott Steinmetz
Scott Steinmetz

Posted on Originally published at scottsteinmetz.biz

FieldOS, Part 3: The App People Open, and What 10 Hours Taught Me About Pricing

Everything in this series so far — the jobs, the parts, the dispatch board, the nine add-ons — runs quietly in the background. None of it matters if the people actually doing the work can't get to it. A technician standing in a parking lot needs a screen that works on his phone. A dispatcher juggling six trucks needs to see the whole board at once. A customer who just wants to know when someone's showing up shouldn't need a password to find out.

So the last piece was building the actual app every one of those people opens — one login, a different view for every role, all running on top of everything from the first two parts of this series.

How It Works

  • One App, Every Role: Thirteen different views live behind a single login — a customer portal plus twelve staff roles, from a technician's field view to a dispatcher's board to an accountant's billing screen. Everyone sees exactly what their job needs and nothing they don't.
  • A Technician's Day, From the Field: Time tracking is now tied directly to the job itself — clock in when a job starts, clock out when it's done, and that time flows straight into the invoice from Part 1 automatically.
  • The Dispatcher's Board: Every open job, every technician's schedule, assign and reassign in a couple of taps — not a phone call and a whiteboard.
  • What Customers See: A customer who reported an issue through the public form from Part 2 can log in and watch it move from reported to assigned to done, and see any quote waiting on their approval — no bookkeeping mess, no calling to ask "any update?"
  • Try It Yourself: A public demo login resets the entire system to a clean starting point every single time, so anyone can click through as a technician, a dispatcher, or a customer without touching real data.

Overcoming the Friction

Wiring a real interface on top of a working system finds bugs that testing pieces in isolation never surfaces. Every one of these came from actually clicking through the app as each type of user, not from a passing code check.

Numbers That Forgot They Were Numbers

The parts inventory screen was sorting and flagging low stock incorrectly — a count of 14 was showing as lower than a count of 5. The cause: those quantities were quietly being handled as words instead of numbers somewhere along the way, and words sort alphabetically, not numerically ("14" reads as "less than" "5" the same way "apple" reads as less than "banana"). Once caught, it was one fix applied everywhere the same data got used.

The Date That Moved Itself

A maintenance schedule saved for the 15th was displaying as the 14th. The calendar field was reading a plain date with no time attached and defaulting to a time zone that shifted it back a day. Fixed by being explicit about the time on every date like this going forward — a small, permanent fix once it was actually found.

A Filing Cabinet Named the Same Thing as a Web Page

Opening the equipment page directly, or refreshing it, threw an error — but only that one page, and only sometimes. The app's own internal storage folder happened to share a name with that page's web address, and the two were quietly stepping on each other. Renaming the internal folder fixed every instance at once.

Eighty-Three Invoices Nobody Asked For

The "try it yourself, no strings attached" demo was supposed to reset everything to a clean slate on every login. It mostly did — except the automatic invoice-drafting feature from Part 1 kept quietly generating a real draft invoice every time a demo visitor completed a test job, and the reset never knew to clean those up. By the time this was caught, 83 fake draft invoices had piled up in the background. Fixed the reset to sweep those up too, then ran it twice in a row and confirmed the count actually stayed flat instead of climbing.

Measure Yours the Same Way

The whole point of building FieldOS wasn't just to have the software — it was to finally know, with real numbers, what a project like this actually costs to build. If you build things for clients and you're guessing at your own pricing the way I was, here's exactly what I did, so you can do it too:

  • Track every stage separately — planning, building, testing, and fixing bugs — not one lump "total time" at the end. They tell you different things about where your hours actually go.
  • Only count time you're genuinely working. A tool sitting open on your screen while you're at lunch isn't billable effort, and it's tempting to let it sneak into the number anyway. Be honest, even when the honest number is smaller than you expected.
  • Do it on one real project you actually finish and ship — not a rough average from memory of past jobs. Memory rounds up. A live-tracked number doesn't.
  • Compare the real number to two things: what you've historically charged for similar work, and what a client would otherwise spend over the next two or three years buying something similar off the shelf.
  • If those two numbers are wildly out of proportion — and they usually are — price against what you replaced for the client, not against the clock. The clock tells you your own cost. It was never supposed to tell you what the work is worth to the person paying for it.

The Business Win

This last piece — the actual app, every role, wired to everything from Parts 1 and 2 — took just under five hours, tracked the same way as the rest of this series: real minutes, planning through testing, nothing rounded up.

Add up the numbers from all three parts of this series: roughly three hours for the core system, about two and a half hours for the nine add-ons, and just under five hours for the app you'd actually hand to a technician or a customer. That's a complete field service platform — fourteen connected pieces plus a real app for every role — built in right around ten hours. Not ten weeks. Ten hours.

FieldOS today is a complete, working system covering every role from the technician in the field to the customer waiting at home. A job can go from a customer's public report to an assigned technician to a paid invoice without anyone touching a spreadsheet once.

Tracking the real hours behind all of it, the way I laid out above, forced an uncomfortable but useful conclusion: pricing this kind of work by the hour badly undersells what actually gets delivered. Ten hours, priced at my old hourly rate, comes out to less than a used car — for a system meant to replace years of subscription software fees. That's the wrong number to hand a client. A system like this needs to be priced against what it replaces for a business — the subscription costs, the slower and clunkier process, the owner's own time spent chasing paperwork — not against how many hours a clock happened to run.

The next phase is already scoped: real-time technician location tracking, a proper visit-scheduling calendar, signature capture on completed jobs, and built-in team messaging — the groundwork for a true mobile app crews can carry in a truck. That build starts as soon as this series is finished.

Top comments (0)