Custom Field Service Software vs. Salesforce: A Cost Case Study

An install job changes hands repeatedly between the first call and completion. At this client — a commercial glass, door and aluminum fabrication company in the Mid-Atlantic — those handoffs lived on a whiteboard, in two working spreadsheets and in managers' heads. The original implementation account described quotes waiting for follow-up and finished installs waiting for paperwork. The practical goal was to make those queues visible.

The owner considered Salesforce and field-service SaaS. The buying question was whether the available configuration, seat model and ongoing support matched this company's work. A fair comparison needed the same users, workflow, integrations and support scope on both sides.

We built a custom field-service system around the company's job stages. This case study explains the operational fit and the cost categories to compare. It does not publish client fees or claim that custom software is always cheaper.

How to compare a configured platform with a custom workflow

Seat licensing, implementation, integrations and support all affect the decision. A configured platform can fit many teams well. For this client, the evaluation focused on whether the system could represent its handoffs without adding workarounds or charging for access that occasional users barely needed.

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.

Make every operational handoff visible

The current project documentation defines ten stages: opened, scoped, quoted, awaiting customer, procurement, scheduled, started, finished, invoice pending and complete. Procurement makes material readiness explicit before installation scheduling. Sales orders share the early stages, then move from procurement to completion without the installation stages. The original dashboard screenshot below shows the earlier nine-stage design, before procurement was added.

Historical dashboard illustration showing the earlier nine-stage workflow. Job counts, ages and quote amounts are interface examples, not measured outcomes or software pricing. The current documented workflow adds procurement.

The dashboard groups work by stage and shows time spent waiting, with configured aging indicators and a stalled-job notification workflow. A row-based view keeps relevant job fields together for office staff. The useful question is whether people can see the next action and its owner, rather than whether the interface uses cards or rows.

Not every condition needs another pipeline stage. A revision or lost-job marker can describe the current record without implying a new kind of active work. Model stages and flags around the team's decisions, then test reporting and exceptions against that model.

Scheduling with visible capacity warnings

The current scheduling design makes each technician’s work visible in a day plan. It supports different crews on different days and allows overlapping jobs when dispatchers need them. Capacity indicators are warnings, not hard booking blocks. The interface should help the dispatcher review the work and travel assumptions before saving.

This screenshot illustrates an earlier scheduling interface. In the current documented day plan, overlaps remain schedulable and capacity indicators warn rather than block.

The acceptance check should include a shared crew, different crews on separate dates, overlapping jobs and an over-capacity day. Confirm that the saved schedule matches the dispatcher’s intent and that warnings are clear. A warning-based design requires operational review; it does not promise that double booking is impossible.

In the normal scheduling workflow, the first crew booking and the move to scheduled happen together. The current system also has a separate administrator-only Change stage path for correcting work completed outside the ordinary flow. That path checks tenant and role, uses optimistic concurrency, and records the supplied milestone information and status change in one transaction. Historical information can remain unknown rather than being invented.

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."

Illustrative technician interface for the ordinary start, time-entry, photo and finish workflow. The displayed hours and job records are examples; an authorized administrative exception follows a separate audited path.

The ordinary finish workflow requires time and photo records before a technician closes a job. Server-side checks enforce the rule rather than relying on a disabled button. Any authorized exception needs its own documented workflow and audit trail.

Photos are downscaled on the phone before upload; documents retain their original form. Failed uploads surface a retry action. Acceptance checks should verify that a job does not silently appear documented when an upload is missing.

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.

Job changes pass through controlled procedures that record the actor, action and relevant old and new values. The activity view turns these into readable history. Access controls, privileged paths and retention still need review; an audit trail is useful only if the events it must record are covered.

Normal technician, accounting and office actions have distinct permissions and completion checks. An administrator correction is a separate audited exception, not permission for a technician to skip stages. Review both the everyday workflow and the privileged recovery path when evaluating the system's controls.

The platform separates company data so more than one organization can use it. Tenant isolation is a testing and operating requirement across records, APIs and file storage. Passing tests is evidence about the cases exercised, not proof that no future defect can expose data.

How to compare five-year field-service costs

Put the same scope on both sides: users and roles, implementation, migration, scheduling, invoicing handoffs, integrations, training, support and changes. Ask which costs recur and which assumptions would change as the company grows.

For custom software, include hosting, monitoring, maintenance, security updates and the process for requesting changes. For a subscription platform, include the edition and add-ons needed by the actual workflow. Neither model makes ongoing ownership disappear.

The comparison below is a decision checklist, not a price quote. Obtain current written estimates for a common scope and compare the full period. Do not extrapolate one client's outcome to a different team.

So where's the AI?

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

The job tracker needs reliable records of bookings and job stages. Its ordinary pipeline does not require a language model to decide crew assignments or status transitions. AI coding assistance during development is a different use from an AI feature inside the product.

AI coding tools supported the implementation, alongside planning, tests and independent review. The delivered design still had to enforce job transitions, authorization, scheduling and data separation. Those controls are what a buyer should inspect; development speed alone is not evidence that the system is ready.

Using AI in development does not require adding a model to the product. Here the product needs reliable records and constrained operations. Keep a reviewable specification and test the consequential workflows regardless of how the code was produced.

The principles underneath

The client's vocabulary informed the specification: stage names, priority levels, service areas and reference IDs came from the existing work. As the process changes, the software and documentation need to change with it. Keeping familiar terms can reduce training friction, but adoption still needs observation and support.

Enforce important rules on the server and in storage where appropriate. Also test privileged paths, recovery and exceptions; a rule can be bypassed if another authorized path was left out of the design.

Design tenant separation deliberately when more than one company will share a service. That can reduce duplicated infrastructure, but onboarding still requires configuration, data handling and acceptance checks.

Use a maintainable stack and make ownership explicit in the agreement: source code, data, hosting accounts, backups and handover documentation. A common framework helps, but a new maintainer still needs a clear deployment and recovery process.

Book a 30-minute call to discuss your workflow, ask questions and decide on a useful next step, with no obligation.