Software that prices the tonnage, runs the crews, and closes the job.

Asphalt paving software is the system a paving company uses to price, schedule, run, and bill paving work in one place instead of spreadsheets and paper. It prices jobs by square foot and tonnage, puts prep, paving, and striping crews on one board, tracks each job against its bid, and invoices the deposit and the final balance from the same record.

Generic field service tools are built for one-visit service calls: quote, visit, invoice. Paving work is project work that stretches across days and phases. The estimate has to carry tonnage, base stone, tack coat, milling, and striping as separate lines. Crews and machines move through prep, paving, and striping in order. Rain moves the whole day, not one appointment. And the job has to be costed against the bid when it closes. When a generic tool cannot do that math, the estimator keeps a spreadsheet beside it, and the system stops being one system.

It starts from the measured area, the depth of the layer, and the density of the mix your plant supplies. The density is the number that matters most: different mixes compact differently, so the system locks the density for the mix on that job instead of using one average figure for every job. The tonnage then flows into the price, the plant order, and the delivery tickets, so the number on the bid, the number ordered, and the number delivered can all be compared at close.

Yes, when the schedule is built around jobs and phases instead of single appointments. Moving one paving day should move the prep crew, the paving crew, the striping crew, the trucks, and the plant order together, and tell the crews and the customers what changed. That is the test to run in a demo: move a rainy Tuesday and count how many places you still have to update by hand.

Off-the-shelf paving and field service products are monthly subscriptions, and the price depends on how many users you need and which features sit on which plan. Mr Task, one paving product we checked while writing this page, lists plans from $39.99 a month with a 14-day free trial and no card required; confirm current pricing on the vendor site before you budget, because list prices and promotions change. Paving-only platforms often quote per seat after a demo instead of publishing a price, so price them for every seat you need.

First phases start at $10000 for a bounded audit, proof of concept, or small first release. A full first release is a larger engagement: our build vs buy guide for paving contractors puts a first release with tonnage estimating, job costing, crew and equipment scheduling, and daily production logs at $110K to $180K over 12 to 16 weeks, and a full platform adding plant order integration, GPS tracking, and DOT reporting at $220K to $360K over 20 to 28 weeks. Those are the bands for paving-specific work, not general software bands. Read the full breakdown in our guide to paving contractor software.

Buy a product when your work fits it: mostly driveways and small commercial jobs, one or two crews, and estimates that a standard quoting tool can handle. Own custom software when the product keeps forcing workarounds: you run 50 or more paving projects a year, you work with several plants whose mixes differ, you need daily reports in a specific state format, or your plant tonnage order has to flow straight from the estimate instead of being retyped by a dispatcher. If the rules of the operation are still changing every week, wait and settle them first.

It must. A site supervisor who cannot log daily production where there is no signal will go back to paper within a week, and the system dies from non-adoption. The field app has to store the day's work on the phone and send it when the signal returns, with a clear state for what is saved, what is waiting, and what failed. Offline working is part of the first release, not a later add-on, because adding it afterwards to a system that was never designed for it is one of the most expensive corrections we see.

By costing the job against the bid while it is still running, not after the invoice goes out. Every hour, machine, load, and receipt is tied to the job, so the job page shows cost against the estimate in real time. At close, the delivered tonnage from the plant tickets is compared with the tonnage on the bid, and the difference is flagged. A timesheet that records hours without saying which job and which phase they went to is a payroll record, not job costing.

Yes. Those are phases and repeat services on the same job record, not separate systems. A commercial lot can move from milling to paving to sealcoating to striping in order, and a sealcoating route can run as a set of small stops with square-foot pricing and repeat visits. The scheduling board has to show paving crews and sealcoating crews together, because the same rain that stops paving stops sealcoating.

Yes, when the accounting product offers suitable access and your controller owns the mapping. Define which system owns jobs, customers, cost codes, invoices, payments, and actuals. Invoices and payments should flow from the job into accounting without retyping, and duplicates, closed periods, and rejected postings need a clear review path. RaftLabs builds the connection; your finance team approves the accounting treatment and controls.

A custom system can, when the daily log data is captured in the right shape from the start. State daily report formats are not uniform, so a contractor working in three states is managing three templates, three sets of fields, and three submission formats. The field data from the daily logs has to flow into the correct format per project automatically, because a supervisor reformatting reports at the end of the day is the work the software is supposed to remove.

Two failure modes cause most of the damage. First, the tonnage and density logic is designed too late: the team starts with scheduling because it is simpler to show, then tries to bolt the estimating engine onto a data model that cannot hold per-mix density locks and change history, and the data layer has to be rebuilt. Second, the mobile app ships without offline working, the crews go back to paper, and the system is never adopted. The density rules and the offline design come first, before any scheduling screen is drawn.

You judge what you can see, not the code. Every checkpoint is working software you click through yourself, tested against the workflow agreed at the start. Progress is reported in plain language: what changed, what's next, and what it costs. Because you own the code, the accounts, and the operating notes throughout, nothing about the work is locked inside our heads. Our job is to make the work checkable; your job is to check it against your business.

You own the code built for you and control where it lives, the cloud accounts, the data, analytics, and third-party subscriptions. Outside services and open-source pieces keep their own licence terms. The operating notes and handover material stay current so another capable team can take over.

We need one person who owns the workflow, access to the relevant users and systems, timely answers on business rules, and someone who can accept or reject each milestone. A weekly working session is usually enough once the scope is stable. Your team should not have to manage developers day to day. The team that scopes your project is the team that does the work: no handoff to another vendor after you sign, and you can talk to the people doing the work directly.