Concrete Contractor Software Problems: The 6 That Cost Real Money, and How to Avoid Them

Why does the weather scheduling scope get built as a calendar so often?

Because everybody agrees on the goal and nobody writes down the rules. The specification says show weather on the schedule and flag at risk jobs, which passes review, and the developer builds a forecast panel next to the job list. Then the first storm arrives and the system flags nineteen jobs, sixteen of which do not care about rain, so the dispatcher goes back to his phone.

Weather sensitivity is a property of the job, not of the day, and it is a short list that nobody thinks to collect during discovery.

• Minimum and maximum placement temperature, and whether the cure window has its own threshold that runs overnight.
• Rain sensitivity before placement, during placement and during finishing, which are three different tolerances.
• Wind and evaporation rate, which decides whether a slab needs a retarder or gets plastic shrinkage cracks.
• Whether the pour is interior or covered, which makes it a weather safe fallback rather than a risk.
• Whether the job can be split, since a footing can often be staged and a monolithic slab cannot.

Get those onto the job record and the same forecast produces a usable answer. The engine pulls the hourly National Weather Service forecast for each site's postcode, evaluates each job against its own thresholds, and flags at risk pours the night before rather than at 5:30am. Then it should go one step further and propose the reshuffle, moving the foundation into Thursday's open plant slot and pulling the garage slab forward, with the messages to plant, pump company and customer drafted so the dispatcher approves rather than dials. A system that only warns has moved the work earlier without removing it.

What goes wrong when you migrate years of jobs out of ServiceTitan or Jobber?

Most concrete companies sit on four or more years of quotes, completed jobs and customer records, and the pitch for a build usually includes mining that history. The mining is real. The data is worse than anyone remembers.

The recurring problems are consistent across shops. Job types are free text, so stamped patio, stamped concrete patio and patio stamped are three categories in the reporting. Customers are duplicated because a homeowner called twice from different numbers. Quotes were revised in place, so the original number is gone and win rate analysis by price is impossible. Costs were entered at job level rather than by line, so you cannot separate labour from material. And addresses are typed rather than validated, which matters because your weather engine needs a location it can geocode.

The approach that works is to clean before you migrate, not after. Normalise job types into a list your operations lead agrees with, deduplicate customers on phone and address, and accept that pre migration costing data may only support trend analysis rather than precise margin. Set a cut off date and treat everything before it as read only reference. Then decide honestly whether you are migrating or integrating, because in most concrete builds the right answer is that ServiceTitan or Jobber stays as the system of record and the new system reads from it. That decision changes the migration from a one time event into a continuing synchronisation, which is a different piece of engineering and needs to be in the quote.

Why do the integrations that matter here break after launch?

Four integrations carry a concrete build, and each fails in its own way once real weeks start running through it.

The ready mix plant is the hardest. Some plants have an ordering interface and most do not, so the practical integration is a structured order confirmation rather than a live booking, and the system needs to model a requested load and a confirmed load as different states. Build it assuming confirmation is instant and every pushed pour creates a phantom booking that nobody at the plant has agreed to.

The pump vendor is the second. Cancellation minimums are contractual and time based, so the system must know your cutoff by vendor and warn before you cross it, not after. A reshuffle that saves a pour and triggers a cancellation charge has not saved anything.

The customer relationship system is the third. Field service platforms rate limit their interfaces, and a nightly full synchronisation of four years of jobs will hit those limits and start failing silently. Incremental synchronisation with a reconciliation pass, plus an alert when records diverge, is the pattern that survives.

The weather feed is the fourth and it is the one people assume is trivial. Forecasts revise, sometimes several times overnight, so the system needs to compare the current forecast against the one it last acted on and only re alert on a material change. Otherwise the dispatcher gets three notifications about the same storm and stops reading them by week two.

What happens when shared equipment and crew constraints are not covered?

This is the operational gap that generic field service scheduling leaves open, and it costs money every week rather than occasionally. You own one boom pump. You run two or three finishing crews. A calendar will let a dispatcher book both crews on pours needing that pump at the same hour, because a calendar models time and not resources.

The consequences are quiet. Crews sit idle on the clock waiting for equipment on the other side of the county. A finisher gets scheduled onto a second job while still committed to the finishing window on the first, which is a physical constraint of the material rather than a preference. Drive time gets ignored, so a plan that looks feasible on the board is impossible on the road. Nobody logs any of it, so the cost never appears in a report.

What closes the gap is treating the pump, the plant's delivery windows and each crew's finishing commitment as hard constraints that block a booking rather than warn about it, with travel time between sites in the calculation. Then capture actual on site and off site times against the plan, because that is the only way you find out which job types and which customers routinely run long. Contractors who add this consistently discover one or two account types that are unprofitable purely on standby and reroute time nobody was recording.

Should you build custom or configure what you already own?

For a large share of concrete companies the right answer is to stay on the product you have. If you run one or two crews doing predictable residential flatwork, quote at low volume, and mainly need a calendar and clean invoicing, ServiceTitan, Jobber or Housecall Pro is genuinely enough. The subscription is far cheaper than a build and it will not fall behind you. Spending six figures to replace a tool that is doing its job is the most common way money gets wasted in this category.

The position worth holding even when you do build is that you should not rip those systems out. They are competent systems of record for customers, jobs and invoicing. Build only for the parts they structurally cannot model, the weather rules engine and shared equipment dispatch, and layer automation on top through their interfaces. That keeps the build small and means a failed project costs you a module rather than your ability to invoice.

Build when the signals stack. Multiple crews sharing one pump. A schedule rebuilt by hand every time the forecast moves. After hours calls going to voicemail. Quotes going cold because nobody followed up. Years of data doing nothing. One of those is an annoyance. Four of them is a business case.

How do hidden costs get into the quote?

The bands here are $50,000 to $120,000 over 10 to 16 weeks for a focused first release covering the weather rules engine, an artificial intelligence phone agent and constraint aware dispatch, and $150,000 to $350,000 over 6 to 12 months for a full operations platform that also mines history and automates estimates, follow ups and reviews. Quotes drift above those numbers in predictable ways.

The largest is plant and pump integration described as an integration when no interface exists, which becomes an ordering workflow plus a confirmation process the vendors have to agree to. Ask what happens if the plant will not participate, because the answer changes the design. The second is a phone agent qualifying both homeowners and commercial general contractors, which is two scripts and two routing paths rather than one agent with a toggle. The third is historical data cleaning, priced almost always as a simple import. The fourth is multi branch rollout, where each location has its own crews, equipment, plant relationships and adoption problem.

What genuinely reduces cost is sequencing. The weather engine and dispatch first, because they remove the most expensive daily pain, then the phone agent, then follow up and review automation, then history mining. Each phase should be usable on its own. A concrete build that ships nothing for six months has already failed regardless of what arrives at the end.

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

The builds that work get used at 5:30am by someone standing in a driveway with cold hands. That sets the bar. The at risk list has to load in a couple of seconds on a phone, the proposed reshuffle has to be approvable in two taps, and the drafted messages to plant, pump and customer have to be good enough to send without editing. Anything requiring a laptop is theatre.

The builds that fail almost always failed at selection. Make a prospective developer whiteboard a weather pushed pour before you sign anything. They should talk fluently about ready mix delivery windows, pump cancellation minimums, cure windows and finisher availability. If they treat a pour as a generic appointment, they will hand you a prettier version of the calendar you already own. Ask for proof they have integrated with ServiceTitan, Jobber or Housecall Pro specifically, and ask what they did when the interface rate limited them. Ask to hear an actual recording of their phone agent qualifying a concrete job, covering tear out, truck access and square footage, rather than a demo script. If they cannot play one, the agent does not exist yet.

Then settle ownership in writing before kickoff. You should hold the repository, the data, the model configuration and the ability to move hosting. And insist on a first release inside weeks with the rest phased behind it, because in this trade a system that does not survive its first storm week is never trusted again no matter what is added later.