Custom Software for Excavation and Grading Contractors

The work is measured in dirt and billed on paper

An excavation contractor knows within a foot how much material came off a pad. What is far less certain, three weeks later in the office, is how many loads left the site on the eleventh, which of them were charged to the customer, how many hours the mini ran while it sat on that job, and whether the quantity billed this month matches what the surveyor says is in place.

That gap is not carelessness. It is the shape of the business. The information that decides whether a site work job made money is generated in a hole in the ground by people whose hands are full, written on a ticket that rides in a truck door for a week, and typed into a spreadsheet by someone who was not there. Every step of that chain loses a little accuracy, and the loss always runs in the same direction — toward under-billing and toward costs landing on the wrong job.

The result is a familiar pattern. The company is busy, the equipment is paid for, the crews are good, and the year comes in flatter than it should have. Nobody can point at the job that did it, because the numbers that would show it were never captured cleanly enough to compare.

Where off-the-shelf construction software breaks

There is good construction software on the market, and a site work contractor should look at it before building anything. It is worth being specific about where those products stop fitting, because the reason is consistent: nearly all of them are built around a general contractor putting up a building, and site work is a different business wearing the same hard hat.

• Equipment is the largest cost, not labor. Products that model a job as hours of skilled trades treat machines as a line item you enter afterward. For an excavator, the machine hour is the unit of production and the unit of cost, and it needs to be first-class.
• Production is measured in quantities, not tasks. Cubic yards of cut and fill, tons of stone, linear feet of pipe or silt fence. A percent-complete field on a schedule is not the same thing, and it is not what the pay application is based on.
• A large share of revenue arrives as a paper ticket. Haul-off loads, imported fill, and stone deliveries are counted by a driver at a scale house or a stockpile. Systems that assume invoices flow from a purchase order have nowhere sensible to put that.
• Unit price contracts are the norm. You are paid for measured quantities in place, not for a fixed scope. The billing question is what quantity was completed this period, which is a field measurement problem before it is an accounting one.
• Moves and mobilizations are real costs. A lowboy trip to relocate a machine costs hours, fuel, and often a day of production, and it usually is not tracked against the job that required it.
• The schedule is weather and dependencies. Rain days, dry-out days, waiting on utility locates, waiting on the surveyor, waiting on the GC to release a phase. Software that assumes a durable schedule spends its life being wrong.

The reliable diagnostic is the same one that works in any industry: find the spreadsheets. In site work they are almost always load counts, equipment hours, and a quantity-to-date tally for billing. Those three are also, not coincidentally, the numbers that determine whether the job made money.

Tickets and hours are the whole ballgame

If an excavation contractor builds one thing, it should be field capture. Not a project management suite — a way for the person who knows the number to record it once, on the day it happened, without leaving the site.

The data set is genuinely small. Which job. Which machine and operator. Hours on the meter, start and stop. Loads hauled, with material and destination. A photo of any scale ticket. Weather if the day was lost. That is a form that takes under a minute, and everything else a site work business wants to know is derived from it.

Two design constraints decide whether it actually gets used. It has to work with no signal — a good share of dirt work happens where there is no service, so the app records locally and syncs when the truck reaches a road. And it has to be faster than the paper it replaces. A foreman will not tap through six screens at the end of a twelve-hour day, and a system people work around is worse than no system, because now the numbers are wrong and the office believes them.

The photograph of the ticket matters more than it looks. It settles disputes with haulers and quarries, it backs up the quantity when a GC questions a pay application, and it means the paper can stay in the truck without the number being lost. The broader pattern is covered in time tracking software for contractors.

Knowing what your machines actually cost

Ask an excavation contractor what their track hoe costs per hour and you will usually get one of two answers: a number somebody quoted them years ago, or a manufacturer figure built on far more annual hours than they run. Both are guesses, and both go straight into every bid.

The real number is not complicated, it is just never assembled. Payment or depreciation, fuel, repairs and parts, undercarriage or tires, insurance, and transport moves, divided by the hours the machine actually worked. Once hours are being captured by job, that division is a report rather than a project, and it answers questions that change how you bid: which units earn their keep, which one is quietly consuming a mechanic's whole year, and whether renting for a specific job beats moving your own machine across the county.

The same hour meter reading also drives maintenance. Service scheduled by hours instead of by calendar is both cheaper and less disruptive, and a machine that goes down mid-job on a unit price contract costs more than the repair. This is the sort of thing that pays for itself quietly and never shows up as a line on any report.

Unit prices, quantities, and getting paid for what you moved

On a unit price contract you are paid for measured quantities in place. That makes billing a field question, and it is where a lot of site work money is left behind.

The mechanics are straightforward and almost always manual. Somebody adds up what was completed this period, compares it against the bid quantities, builds a pay application, and submits it. When that happens once a month from memory and a pile of tickets, two things go wrong. Quantities get missed, particularly the incidental ones — extra undercut, additional stone, a stretch of silt fence repaired after a storm. And overruns get discovered late, when the quantity is already 30 percent past the bid and the conversation with the GC is a fight rather than a notice.

A system that carries the bid quantities and accumulates completed quantities from field entries turns both into ordinary information. Quantity-to-date against bid, per line item, visible while there is still time to act. Extra work flagged as it happens rather than reconstructed for a claim. The pay application assembled from records instead of recalled. How that connects to the original estimate is worth reading alongside custom estimating software.

The paperwork that nobody scopes for

Site work carries a compliance load that is small per item and expensive when it slips. It is also nearly always tracked on a whiteboard or in one person's head.

• Utility locates. Tickets have a start date and an expiration, and they have to be refreshed for work that runs long. An expired locate is a stopped crew at best and a struck line at worst.
• Erosion control inspections. Self-inspection on a schedule and after qualifying rain events, with records that hold up if an inspector asks. This is a recurring, date-driven obligation that a calendar reminder handles badly.
• Dust, haul routes, and permit conditions. Local conditions vary by jurisdiction and by job, and they tend to live in the permit packet rather than anywhere a foreman will see them.
• Equipment inspections and operator records. Daily walkarounds and certifications that matter the moment something goes wrong.
• Subcontractor and hauler insurance. Certificates that expire quietly, usually noticed when a GC audits or a claim gets filed.

None of this is hard software. It is dates, owners, and evidence — the thing a system is genuinely better at than a person with a full plate. The value is not that the tasks get done differently, it is that the record exists without anyone assembling it after the fact.

What to build, in what order

The most common failure in a contractor software project is scope. Trying to replace accounting, estimating, scheduling, and field operations in one build is a long project with a real chance of collapse, and it is not necessary.

Leave accounting where it is. Payroll, receivables, payables, and the general ledger are the standard part of your business, and QuickBooks or a similar package handles them fine. Build the operational layer where site work is genuinely different, and push finished invoices and cost entries into accounting so nobody rekeys anything — the patterns are covered in custom software with QuickBooks integration.

Sequence it so each piece stands on the last. Field capture first — tickets, hours, materials, photos — because everything downstream depends on that data being real. Job costing second, since it is now mostly reporting against records you already have. Quantities and billing third, because they build on the same field entries. Equipment costing and maintenance after that. Compliance tracking whenever it starts costing you, which for most companies is sooner than they expect. What job costing looks like once the inputs are trustworthy is covered in job costing software for small contractors.

When you should not build anything

Three situations argue against a custom build, and each is worth ruling out first.

If you run a handful of machines on lump sum residential work and your jobs finish in days, the overhead of any system may exceed what it saves. A disciplined spreadsheet and a habit of collecting tickets weekly will get you most of the way.

If you already pay for software with modules you have never switched on, look there first. A number of contractors are paying for equipment tracking or field entry inside a product they already own and worked around it because setup stalled a year ago.

And if the underlying problem is that nobody agrees on the process — tickets handled three different ways depending on which foreman is running the job — software will encode the confusion rather than fix it. That is worth settling before a build. How to tell the difference is covered in seven signs your business has outgrown its software.

How we approach it

Brad Walker has spent more than twenty years building operational systems for contractors, manufacturers, and service businesses from Wake Forest, NC. A site work engagement starts by following one job from bid to final pay application — where the quantities came from, how hours and loads got recorded, what got billed, and where a number was typed twice or never at all. That trace usually explains most of the difference between the bid and the result, and it defines a build small enough to finish.

Engagements are fixed price, with the scope agreed before development starts. You know what you are getting, what it costs, and when it lands.

Frequently asked questions

If your load counts live on paper in a truck door, or nobody can say what a machine costs you per hour, that is a fixable problem — and a smaller build than it feels. Start the conversation. The first step is a discovery call to trace one job from bid to final billing and find where the margin went.