Mach9's $34 Million Round Targets the Work After the Scan

Recognizing a curb is not the same as deciding exactly where its edge belongs in an engineering drawing, especially when the pavement is broken, the scan is incomplete or a ramp interrupts the line. That distinction runs through Mach9's new financing announcement. The company is selling faster conversion of captured reality into usable drawings, with professionals still reviewing the result. Its most revealing customer examples are the ones that describe what the software does not finish automatically.

On October 21, Mach9 announced a $34 million Series A co-led by First Round Capital and Bessemer Venture Partners, with Prudence and Quiet Capital participating. The company says the round brings total funding to $49 million. TechCrunch independently reported the financing and interviewed co-founder and CEO Alex Baikovitz. The announcement also reports more than 2,500 projects across all 50 states and over 100,000 miles of infrastructure surveyed using the software. Those adoption figures are company disclosures, not an independently audited measure of recurring use.

Baikovitz told TechCrunch that the business began in 2021 as Mach9 Robotics, pursuing better inspection hardware. Customer conversations redirected it toward the labor required to turn scans into engineering information. That history matters because the current product does not ask buyers to start by replacing their capture equipment. A hardware company discovered that the useful commercial opening was downstream of the sensor. The funding backs that software direction, rather than announcing a newly invented scanning device.

Mach9's product description sets out four stages: upload scans, obtain automatically drafted features, refine them with CAD tools, and export the deliverable. Supported inputs span mobile, terrestrial and drone capture. The proposed output includes curbs, striping, poles, signs, breaklines and surfaces. Customers can edit geometry before exporting to formats including DXF and DGN or to Esri Feature Services. This is an important boundary around the pitch. A first draft is an intermediate work product, even when it looks complete.

The software's claimed centimeter-level accuracy needs the same care. The public product page does not establish that every feature, input dataset and operating condition achieves one universal error bound. Buyers should ask what the number measures, which reference establishes it and which cases are excluded. A missed object, a wrongly classified object and a correctly classified object with misplaced geometry are different failures. An acceptance test should keep them separate instead of collapsing them into an impressive accuracy percentage.

The mechanism described in Mach9's March platform announcement is more specific than a generic promise to apply AI to CAD. Its extraction engine suggests linear features from point clouds and adapts suggestions to a user's drawing patterns. Geometry remains editable, and reviewers can inspect it in three dimensions. That gives the operator a way to intervene during production. It does not establish how the underlying model was trained or provide independent evidence that adaptation improves accuracy across all customers.

One older integration announcement shows why the surrounding data handling deserves attention. Mach9 says native support for Leica's LGSx format brings in point clouds, panoramic and planar imagery, and project metadata such as units and georeferencing. Previously, the described workflow involved separate LAS and image exports with manual configuration. This is not an October product launch; it is an existing capability relevant to the financing thesis. Retaining the context around a scan can matter as much as extracting another class of object.

For an engineering team evaluating the system, the useful question is whether imported geometry and metadata survive the complete trip into the final deliverable. A successful upload is too early to declare victory. The practical test should include the actual downstream file, its coordinates and units, and the corrections required by the person accepting it. Mach9's integration strategy offers a plausible way to reduce these handoffs. The claim should be assessed at the handoff, not inferred from the presence of a supported file extension.

The Olsson case study makes the distinction between computation and completion unusually visible. In Mach9's account, a three-mile highway corridor produced a first-pass extraction in 15 minutes. The same page reports 90 percent of features extracted on the first pass and a 60 percent faster survey-to-CAD workflow. These are three different measurements. Fifteen minutes is not the duration of a finished highway survey, and 90 percent coverage is not a statement that positional accuracy is 90 percent.

Olsson's described workflow still includes verification, editable linework and follow-up collection where the scans fall short. The case therefore supports a narrower and more credible proposition than eliminating survey work: move technicians from drawing everything to assessing an initial result. Whether that saves time on a particular contract depends on the burden of the remaining exceptions. A buyer should deliberately include incomplete capture and difficult geometry in a pilot, rather than demonstrating only a corridor that already suits the extractor.

Pennoni's example points to a second source of value: coordination. The vendor-hosted case describes technicians splitting work among several applications, exporting and merging outputs, and checking that geometry and units remained consistent. It says Pennoni ran a three-week pilot before expanding adoption. The reported result is a 50 percent increase in project capacity without additional headcount, alongside 60 percent faster survey-to-CAD workflows. Those numbers describe this customer's experience as presented by the supplier, not a general staffing formula.

The same account identifies aprons and curb ramps as features that can still require manual quality control. That is useful detail for a purchasing team because it names work to test, not merely a benefit to admire. Capacity also has a different denominator from speed. A faster drafting stage might create room for additional projects, but it does not by itself establish new revenue, higher margins or a shorter construction schedule. The commercial outcome depends on what the firm can actually sell and deliver with the released time.

Mach9's Michael Baker International case expands the discussion beyond drawing lines. It describes a state transportation sign inventory spanning more than 2,500 miles and over 65,000 assets, with reported accuracy above 99 percent. The workflow associates sign faces with assemblies, applies Manual on Uniform Traffic Control Devices codes, and lets the production team review and approve the records in a shared environment. The state customer is not named on the page. Nor does the headline percentage provide a complete definition of the error metric.

That distinction matters for asset management. Finding a sign is only one part of producing a useful inventory; associating it with the right assembly and record is another. Buyers should request the error breakdown for the fields they intend to use. The case is evidence of a described production workflow, not independent certification that every sign complies with a standard. Software-generated classification should not silently become a stronger assurance than the source material supports.

Fibersmith's Carroll County, Maryland, example shows a different payoff from richer capture. According to Mach9's case study, the team collected data across nearly 400 miles in three days. When the intended construction approach changed from underground to aerial, the previously collected data allowed the team to proceed without another site visit. The account attributes a fifteenfold workflow improvement to mobile mapping combined with automated extraction. It would be misleading to assign that entire gain to Mach9's software alone.

The qualification on visibility is equally important. The case describes assets within the capture system's field of view; it does not demonstrate that a road scan reveals concealed underground infrastructure. The narrower lesson is still valuable: collecting usable information before every design choice is fixed can preserve options later. For a buyer, that makes completeness of relevant capture and access to the underlying observations part of the purchase decision, rather than treating the extracted asset list as the only valuable output.

Langan's nine-mile California desert project offers the clearest counterweight to an effortless-automation narrative. The vendor case describes poor delineation, broken lines and irregular terrain. The team used manual extraction for detailed structures, cleaned up pavement edges and used cross-sections to inspect elevations. It reports finishing a week ahead of schedule and 30 percent under budget. Those are project-specific outcomes. The operationally interesting detail is that manual work remained inside the same production environment instead of becoming an unplanned detour.

Taken together, these cases suggest that exception handling is part of the product's value, not an embarrassing residue to hide. A system that accelerates easy features but makes hard ones painful could lose its advantage during review. Conversely, keeping corrections close to the source scan can make an incomplete first pass useful. That is an interpretation of the workflows described here, not a measured comparison with competing tools. The published accounts do not supply a controlled, common dataset for such a ranking.

The marketing figures themselves warrant restraint. March's platform announcement referred to users reporting up to 100 times faster completion. October's financing release describes up to ten times faster work at one-fifth the cost. Neither figure should be substituted for Olsson's elapsed extraction time or Pennoni's capacity increase. The reviewed pages do not provide a shared test protocol that reconciles these claims. Without matching task definitions and starting conditions, lining the multipliers up in a chart would create more apparent precision than information.

A serious pilot should therefore record the whole sequence on representative work: preparation, upload, first extraction, correction, independent review, export and any return to the field. Compare the accepted result against an agreed reference, including missing features and false detections as well as geometric discrepancies. Keep operator time separate from machine time. These are proposed purchasing tests, not benchmarks we performed. They follow directly from the gaps between the initial draft and final acceptance described in the customer accounts.

The financing gives Mach9 resources to expand, but the material reviewed here does not disclose the retention, realized customer economics or independently reproduced accuracy needed to settle the commercial argument. The case studies are published by Mach9 and are not independent evaluations. TechCrunch provides independent reporting on the business and the CEO's account, not a technical validation of every performance claim. That sourcing limit belongs alongside the results, particularly when the numbers will influence a buying decision.

The compelling part of the business is its placement between existing capture equipment and existing engineering deliverables. It can seek value from a slow production stage without requiring a customer to replace the entire design stack. Whether it earns that position will depend on the work after the first draft: how efficiently a reviewer can find the wrong curb edge, correct it and deliver a drawing the next engineer can use. The next useful proof is an accepted project with the review bill included.

LaunchPad positionTest the accepted deliverable, including correction, review and export time. Keep extraction speed, team capacity and geometric accuracy separate when evaluating the vendor's claims.