From paperwork to pipeline: 86% less than the Salesforce alternative

An install crew's job changes hands nine times between the first phone call and the check clearing. At this client — a commercial glass, door, and aluminum fabrication company in the Mid-Atlantic — those hand-offs lived on a whiteboard, in two working spreadsheets, and in whatever the managers could keep in their heads. Nothing ever crashed. Things just went quiet. A quote would sit for three weeks waiting on a customer nobody re-called. A finished install would sit unbilled because the paperwork hand-off happened out loud, or didn't happen at all.

The owner did what owners do: went looking for software. The Salesforce conversation produced a number that stopped it cold — $4,000 for implementation, then per-seat licensing on top, forever. At Salesforce's published list prices, Field Service seats run $165 per user per month on Enterprise and $330 on Unlimited, and Field Service sits on top of Service Cloud licensing besides. Put ten people on it and you're near $1,700 a month before anyone has customized anything. The field-service SaaS market wasn't much friendlier: the tools that actually fit — Jobber, Service Fusion, Zuper, FieldPulse, Workiz — landed between $250 and $600+ a month, each one carrying features this company would never touch and missing vocabulary it uses every day.

We proposed something different: custom field service software built around exactly how their jobs move, at 86% less than the Salesforce route over five years. This article walks through what that bought — what each piece is, how it works, and why it's built the way it is.

The Salesforce quote that didn't fit the company

The problem with enterprise field-service pricing isn't that the software is bad. It's that the pricing model punishes exactly the kind of company that needs it. Seat-based licensing means every glazier, every helper, every part-time accountant is a monthly line item. The implementation fee buys configuration, not fit: your nine-stage reality gets mapped onto the vendor's object model, and where they disagree, you lose.

This company's reality was specific. Jobs arrive by phone, email, and walk-in. An estimator scopes, a quote goes out, and then the job waits — sometimes weeks — on the customer. Accepted work gets scheduled against a small set of crews. Techs work the job, log hours, take photos. Paperwork goes to the accountant, and the owner personally reviews every job before it closes. Two working spreadsheets held the vocabulary: a priority scale (routine, urgent, emergency), service areas, and a job-reference ID from their quoting system with formats like Q115931 and 2600037.

None of that is exotic. All of it is theirs. The build's first rule was that the software would speak the company's language instead of teaching the company a vendor's — the stage names, the field names, and the ID formats came straight out of the sheets they already ran the business on.

Nine stages, because the work has nine hand-offs

The office view is a pipeline of nine stages: opened, scoped, quoted, awaiting customer, scheduled, started, finished, invoice pending, complete. Not five. Not a generic "in progress." Nine, because a five-stage board would have hidden the four places where jobs actually stall: the site visit that produces a scope, the wait on the customer's answer, the paperwork sitting with the accountant, and the owner's final review. Each of those is a spot where a job stops moving and, on a whiteboard, nobody notices.

The dashboard makes stalling visible instead. Every row shows how many days a job has sat in its current stage, with a heat indicator that goes amber and then red against thresholds the company sets per stage. A daily sweep emails the office about jobs that have gone quiet. The board is nine stacked, sortable, filterable sections rather than a drag-and-drop card wall — deliberately. A row can carry all nine things the office needs to see about a job; a card carries four. And dragging cards is how statuses get changed by accident.

Two states that look like stages aren't: "needs revision" and "lost" are badges on a job, not columns. A lost job isn't a tenth kind of work in progress, and a revision is the third pass through quoting, not a different job. The estimating sheet already treated them that way; the software just agreed.

Scheduling that won't double-book a crew

Scheduling is where field-service software usually earns or loses its keep. Here it's three layers deep. As a dispatcher picks a date, the panel shows live availability per technician — the workday minus every window already committed. On submit, the server re-checks. And underneath both, the database itself carries an exclusion rule that makes overlapping bookings for the same technician on the same day physically impossible to store.

That third layer matters because the first two can race. Two dispatchers booking the same crew in the same second will both pass the on-screen check. One of them will hit the database rule, and instead of a cryptic error the panel states the conflict in plain language — who's already booked, for which window — and refreshes what's still available. The wrong outcome (two crews promised, one shows up) is not an error message. It's unrepresentable.

A job only enters the scheduled stage in the same transaction that writes its first crew booking. There's no "mark as scheduled" button, because a status that can disagree with the calendar is worse than no status at all.

The technician's day, on the phone in their pocket

Technicians never see the office dashboard. Their surface is built for a phone in a work glove: today's jobs, the site address, the crew window, and two buttons that matter — start and finish. Time entry is deliberately not a punch clock. Job sites have dead zones, and a live timer is only as good as its offline story, so techs log hours the way they already think about them: "4.5 hours on this job today."

Finish has a gate. A job cannot be marked finished until it carries at least one time entry and at least one photo, and that rule is enforced in the database, not in the button. Any tech on the crew can close the job, which is exactly why the server is the one checking. A job marked finished with no hours and no photos isn't a record of anything, and it's on its way to becoming an invoice.

Photos get downscaled on the phone before upload so a day's documentation doesn't eat a data plan; documents don't, because a resized estimate PDF is a destroyed estimate PDF. A failed upload retries, then surfaces a per-file retry button. A photo is never silently dropped.

The parts you only notice when they're missing

Some of what we built doesn't show up in a screenshot, and it's the part we'd argue matters most.

Every change to a job — every field edit, every stage move, every quote amount — writes an audit entry: who, what, when, old value, new value. This isn't an optional log. The database refuses direct edits to jobs entirely; the only path to changing one runs through procedures that write their own audit trail as they go. The activity rail on each job reads as English sentences ("Set the quote to $4,200.00," "Assigned a new estimator"), so "who changed this and when" stops being a meeting.

Roles are enforced the same way. A technician can start and finish jobs — and can't touch a quote, reassign work, or skip a stage, no matter what the client-side code asks for. Closing a job is the owner's review gate alone. The accountant records the invoice number; the owner closes the job. A gate one person can both trigger and satisfy is not a gate.

And the whole thing is multi-tenant: the platform was built from day one to run more than one company, with 247 of its 617 automated tests doing nothing but proving that one tenant can never see another tenant's jobs, photos, customers, or history — down to the file-storage layer. That decision is also the economics, which brings us to the price.

How custom field service software comes in 86% under Salesforce

The honest version of the math: this build took about 110 to 150 hours of engineering across nine phases — database and tenancy, the job pipeline, the technician surface, files, admin, scheduling, notifications, customers, and a verification pass. At typical agency rates, that's a five-figure project on a multi-month calendar. It shipped for a flat implementation fee a fraction of that size because it didn't take typical agency throughput, and because the monthly fee isn't rent — it's a budget.

Infrastructure for this platform costs less per month than a single Salesforce seat. The rest of the monthly fee buys development hours, which is how the platform keeps growing after launch — the next phase ships a few hours at a time instead of as a new engagement with a new invoice. And because the platform is multi-tenant, the client's growth plan (they're acquiring other glass companies) doesn't multiply the software cost: onboarding an acquired company is hours of setup on the same monthly fee, not a second build.

Compare the five-year picture. Salesforce Field Service at ten seats, list price, comes to about $99,000 in licensing — north of $100,000 once the $4,000 implementation is in. The mid-market SaaS tools land between $15,000 and $36,000 — for software that still doesn't know what a TRUE ID is. This platform came in 86% under the Salesforce total, for software with their stage names, their vocabulary, their rules — and they can add the next acquired company without a new line item.

So where's the AI?

Nowhere in the product, and that's the point.

There's no chatbot on the dashboard, no model deciding which crew to send. A field-service tracker is a system of record: its job is to be boringly, provably right about who's booked where and what stage a job is in. Nothing in that problem is a language problem, so nothing in the product is a language model.

The AI is in how the platform got built. The scoping call happened on a Tuesday. The specification — nine stages, five roles, every field with its rules — was settled by Thursday. The following Sunday, the platform was in production. In between: nine build phases, each run through the same loop — research, plan, an independent check on the plan, implementation, then verification and code review by a separate process that doesn't trust the implementer's word. 386 commits and 617 automated tests later, the delivered system had survived seven independent review passes that found and fixed 49 issues before any user ever could.

That pipeline — AI agents doing the throughput, with verification gates a human team would recognize — is what collapses a five-figure, multi-month engagement into a five-day one at a fraction of the cost. Same lesson as every build we ship: the expertise isn't adding AI to the product. It's knowing where AI belongs. Here it belonged in the factory, not the machine.

The principles underneath

Wondering what the custom-build math looks like for your operation? Book a 15-minute call and we'll walk through it: what you're paying now, what a right-sized build would actually cost, and whether it's worth doing at all. No pitch — you leave with a plan either way.