Bringing LiDAR and AR Damage Measurement to a Road Repair SaaS Platform

Yes, provided the target devices carry LiDAR hardware (iPhone/iPad Pro models with Apple’s LiDAR Scanner). The harder part isn’t the sensor API, it’s the app’s existing measurement logic: whatever manual or estimate-based approach is already there needs auditing so the new capture path replaces it cleanly instead of running as a second, inconsistent source of truth. On this project, that audit is also where MobiDev found the client’s original computer-vision-only plan couldn’t deliver reliable depth, which is why LiDAR was recommended in its place.

It can. AR overlays usually ask users to hold a device at a steady distance and angle, a different habit than framing a static photo, so any workflow that changes that physical motion needs an adjustment period built into rollout. Here, reps already used the live camera to log a job, so the overlay was layered onto that same camera view rather than adding a new capture step, meaning the change was in what appeared on screen, not in how a visit was physically run.

It depends on whether the current logic outputs anything structured enough for a new capability to build on. A legacy feature that just stores a user-typed number gives a CV or sensor layer nothing to attach to, and needs its own data path first. That’s exactly what the audit here found: the platform’s existing logic was user-estimated rather than computed, which is why the recommendation was to replace it outright with LiDAR instead of adding a new measurement source alongside it.

Build cost covers sensor integration, AR rendering, and calibration, largely a one-time engineering cost. Keeping the core volume calculation on-device rather than server-side, which is how this was built, keeps that recurring cost closer to a rounding error than a real line item.

A labeled set of images for each surface type, but it doesn’t have to be collected from scratch: public datasets such as StreetSurfaceVis (about 9,100 street-level images labeled asphalt, concrete, paving stones, sett, and unpaved) give a model a starting point. Even so, a classifier may not be the best fit here, since a simple surface-type switch in the interface lets the user set it in one tap without any modeling work. The more useful computer vision task on this platform is edge detection, which finds the boundaries of a pothole automatically instead of relying on the user to mark them, and it needs no training dataset at all.

Worth separating what a sensor does from what a model does. LiDAR gives raw geometry, depth, width, volume, and that’s realistic today on any device with the hardware. Computer vision sits above it for interpretation: identifying a surface type, judging severity, spotting a pattern, and that layer needs real training data, which is exactly the kind of feature that gets pitched as “it’ll just know what it’s looking at” and quietly shelved once the data requirement becomes clear. That’s the split that played out here: the client initially wanted a CV-only feature, the audit showed CV alone couldn’t hit the needed depth precision, so LiDAR became the core measurement layer, with CV reserved for the not-yet-committed surface classification phase.

It speeds up the routine scaffolding around a feature, UI code, API clients, test stubs, but the core scanning and calibration logic touches sensor math and coordinate transforms, where a subtle generated error (a unit mismatch, a wrong coordinate frame) produces a measurement that’s confidently wrong rather than obviously broken. That logic still needs an engineer who understands the sensor reviewing it line by line. On this build, generated code handled the surrounding app work, but the scan-to-volume calculation itself was hand-reviewed given that it feeds directly into a customer’s quote.

It is when the team controls what the AI tools can see: business-tier tools that don’t train on submitted code, access limited to the repositories a task needs, and API keys, credentials, and real customer data kept out of prompts entirely. On a platform like this one, that data includes scan results, site photos, and job locations, so development and testing run on synthetic or anonymized samples rather than production records. Generated code also goes through the same security review as hand-written code before release, because a tool can suggest an insecure pattern just as easily as a correct one.

Reliable enough that the error it introduces costs less, on average, than the error in the manual method it’s replacing, which means testing across lighting, surface wetness, distance and device model rather than just a controlled demo. That bar matters more here than in most consumer apps, since a bad reading turns directly into a wrong material quote and a real cost to the customer, not just a minor inconvenience.

A proof of concept validating core scanning and overlay accuracy typically takes a small number of weeks. Full build and rollout takes longer, driven by how much of the existing app’s data model and UI has to change, plus platform quirks, since ARKit and ARCore don’t behave identically, plus only Pro iOS devices have LiDAR, and very few Android devices have a ToF sensor (analog of LiDAR), and without proper hardware, the functionality may be limited. The sequence here followed the audit into proof of concept into delivery, with support and further features continuing well after launch rather than the engagement ending at ship.

When the gap is technical approach rather than effort, meaning the same category of problem keeps recurring even after feedback, which usually signals a mismatch between what the team knows how to build and what the product needs, not something more oversight fixes. That was the situation here specifically around measurement precision, which is why the client wanted a partner able to evaluate LiDAR against the CV-only approach they’d originally asked for, rather than one that would have just built what was requested.

Build it, because a volume calculator is a small, specific piece of logic rather than something worth licensing. Once LiDAR has captured the depth, width, and length of the damage, the material estimate is a straightforward multiplication, and even unit conversion is a few lines of code rather than a reason to buy a tool. Building in-house also means the calculator takes the scan data directly and follows the platform’s own rules for materials and pricing, instead of forcing that data into a generic tool’s inputs.

Quoting and invoicing systems most commonly, so a field measurement becomes a customer-facing quote without manual re-entry, and CRM integration is common too, logging the visit against a job record automatically.