Land Surveying Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does crew dispatch get scoped as a calendar?

Because that is what every adjacent product looks like, and because the request sounds simple. Somebody says they need to see who is going where tomorrow, a developer shows a drag and drop board, and everyone agrees it is an improvement on the whiteboard. It is, marginally, and it leaves the actual problem untouched.

Scheduling a survey crew is a constraint problem wearing a calendar's clothes. Seven things have to line up at once, and six of them live in different places. The party chief's licence and its state, the instrument class the job needs against what the crew has, drive time from the previous stop, right of entry status, locate ticket number and expiry, whether control from a prior visit is still recoverable, and the client's access window. General field service products model a technician and an appointment, which is correct for trades and structurally wrong here, because none of them know that a rover is the wrong instrument for a heavy canopy topo or that a locate ticket expires on a date.

So the constraints stay in the coordinator's head, which is why the board degrades the week they take leave and why nobody else can rebuild it.

Specify the crew, the instrument and the certification as entities with real attributes rather than as labels on a schedule. Party chief carries licence number, state, expiry and cleared job types. Instrument carries type, calibration date and current assignment. Job carries required instrument class, required certification, right of entry status, locate ticket and expiry, and access window. Then dispatch proposes a board and shows violated constraints before anyone commits, and when an instrument goes out of service the system names the four assignments across the next fortnight that just became invalid. That behaviour is the highest return item in this category and no general product will ship it, because the constraint set only exists in surveying.

What goes wrong when you migrate the job log and the shared drive?

The spreadsheet is the easy half. Job numbers, clients and dates import cleanly in a few days, and everyone concludes migration is straightforward. Then you reach the shared drive.

Files are organised by whatever convention each office adopted, plus the exceptions each project manager introduced. Folder names carry job numbers in three formats. Some jobs live under the client rather than the number. Acquired offices brought their own scheme entirely. There is no reliable link between a folder and a job record, which means linking the two is a parsing exercise with a manual reconciliation pass behind it, not an import.

The content problems follow. Deliverables exist in several versions with no marker for which one was sealed, field notes and photographs sit in message threads, and prior monument recovery notes exist as a line in a drawing rather than as a record you can search.

Do this deliberately. Import structured job history in full, link the most recent two years of folders to job records by path parsing plus a review pass, and leave older archives searchable but unlinked rather than pretending the link exists. Budget two to three weeks inside the project rather than a weekend. And treat the monument and control database as a build item rather than a migration item, because going forward it becomes an asset that makes every future job in that county cheaper to field.

Why does the accounting integration break after launch?

Deltek Ajera and Vision are the largest cost and schedule variable in this category, and the failures are not one off. They recur.

The data models do not map cleanly. An accounting system organises around a project and its budget; an operational system organises around a job and its state, and the two disagree about what a phase is, when work is billable and what happens to a job that splits. Sync therefore needs explicit conflict rules rather than a nightly copy, and those rules have to be decided by your controller rather than assumed by a developer.

Then it drifts. Someone adds a project type in accounting that the sync does not recognise. A field your staff repurposed for their own use gets overwritten. An upgrade changes an endpoint. On premises installations behave differently from hosted ones and get patched on a schedule nobody tells the operations team about. The failure mode is a sync that keeps running and quietly stops carrying some records, which is discovered when a month's billing is short.

Insist on three things in the scope. A reconciliation report comparing record counts and totals on both sides, on a schedule, reviewed by a named person. Quarantine rather than silent skip for anything the sync cannot map. And an explicit budget line: three to five weeks for a genuine bidirectional sync, more on an older on premises install. A vendor who has never touched Deltek will quote two weeks and spend six, and the six comes out of your schedule.

What happens when licensure, right of entry and locates are not enforced?

These are the constraints firms assume everyone knows, which is exactly why they get left out of a specification and then cause the failures the project was commissioned to stop.

Licensure is the sharpest. A job type dispatched into a state where the assigned chief is not licensed is a problem that does not resolve itself, and the seal at the end of the process is the point at which it becomes visible to someone outside the firm. The system should carry each licensed surveyor's number, state and expiry, block dispatch that would violate it, and require a seal transition on the job state machine before delivered status is reachable. The audit trail that produces, showing who sealed what and when, is stronger evidence than a shared drive folder if you are ever in a claim.

Right of entry and locate tickets are the ones that cost crew days. A ticket has a life, and a job dispatched against an expired ticket is a wasted mobilisation and a genuine safety exposure. Right of entry that has not been executed produces a crew turned away at a gate. Both are knowable the afternoon before, and both should block a dispatch rather than appear as a note somebody may read.

Should you build custom or configure what you already own?

Configure, genuinely, if you run five crews or fewer from one office, mostly residential boundary and mortgage inspection work, one instrument ecosystem, one state. Your constraint set is small enough to live in a good coordinator's head, and Deltek Ajera plus a disciplined shared drive plus a whiteboard will beat a build you have to maintain. Spend the money on a second robotic total station instead. Anyone telling a firm that size to commission custom software is selling hours.

Be precise about what Ajera is and is not. It is strong at time, billing and project accounting, and it tracks money against a project rather than the state of a deliverable, so it does not know whether a job is field complete, sitting in drafting or waiting on a seal. Most firms that build keep Ajera for accounting and put the operational layer on top with a sync. Replacing it outright is almost never worth the risk or the money.

The signals that building is now cheaper: your coordinator cannot take two weeks off without the board degrading; you cannot state your drafting backlog in days without asking three people; you re mobilise crews more than twice a month for knowable reasons; you have acquired a firm or are about to; or licensed staff are spending real hours transcribing title commitments.

How do hidden costs get into a surveying software quote?

• Deltek integration. The single biggest variable. Three to five weeks for a real bidirectional sync, more on older on premises installations, and it belongs on the quote as its own line.
• Raw file formats. Every additional instrument ecosystem adds parsing and testing. If your fleet is mixed, say so on day one rather than in week ten.
• Offline first field capture. Roughly double the cost of a web form, because conflict resolution when two crews sync the same job is real engineering and not caching.
• Each additional state. Right of entry rules, locate rules and seal requirements differ, and each is configuration surface with its own testing.
• Shared drive linking. Two to three weeks of parsing plus manual reconciliation, frequently omitted entirely.

For orientation, Digital Heroes delivery experience puts a focused first release covering the constraint aware scheduler, the job state machine and offline field capture at $60,000 to $130,000 over 12 to 16 weeks, with a full platform at $150,000 to $400,000 phased over 6 to 12 months.

What separates a build that works from one that fails here?

Whether the job state machine is real. Ask the developer to draw the job entity before anything is signed. If their record does not distinguish research from field ready from field in progress from field complete from data reduced from drafting from quality review from sealed from delivered, they will build a work order system with survey words on it, and your drafting queue will stay invisible. The state machine is the product. Firms that get it right discover, often for the first time, that most of their cycle time is drafting rather than field work, which changes where they hire next.

Whether the crews trust the field application in month two. It has to work with no signal, and the answer to how offline conflicts resolve cannot be that the application caches locally. You want a description of what happens when a party chief edits a job on a tablet with no service while the office edits the same job, and how the merge resolves without dropping a field note. A crew that loses one note to a sync bug stops trusting the application permanently, and no amount of later engineering recovers that.

Whether adoption was planned. Put two party chiefs in the design sessions from the first week and run a single crew pilot before firm wide rollout.

And whether you own the result. Repository, cloud accounts in your own name, and an unrestricted right to hire anyone else, settled in the statement of work before signature. At Digital Heroes the client owns the code from the first commit. This matters more here than in most industries, because your monument recovery records and control network history compound into an asset, and a firm holding them inside its own tenant has a hold over you indefinitely.