You ran the estimate, assigned the job, and watched it disappear into the queue. By the time parts arrived, the tech had moved on. The supplement from the insurance adjuster sat in email for four days because nobody connected the estimating platform to anything that could flag it. The car sat an extra week. The customer called twice. The existing auto body shop software did not prevent any of this.
The collision repair category has market-leading products that have been in use for 20 years. Most of them digitized the paper workflow instead of redesigning it. The shops that run well have built workarounds — human systems layered on top of software systems — and called that operational excellence. An operator founder who's lived inside that tension for a decade sees it differently: the software is the constraint, not the people using it.
How a single repair job becomes a coordination nightmare
The job order lifecycle in a collision shop is predictable: write the estimate, get insurance authorization, order parts, assign the tech, complete teardown, write the supplement for additional damage, get supplement approval, finish the repair, QC, deliver. In a well-run shop this takes two to four weeks. In most shops, the software friction adds three to five days on top of that.
The core problem is data handoffs. The estimating tool generates a job with specific parts and labor. Parts ordering lives in a separate system. The tech's job card is either a paper ticket or a siloed module that doesn't push updates anywhere. Customer communication is manual. Each transition requires someone to move information from one system to another — usually by printing, retyping, or walking across the floor.
Why insurance integration is where every product falls short
Insurance work is where most collision revenue lives and where most operational pain concentrates. A supplement — additional damage found during teardown — triggers a secondary approval cycle that can take three to seven days depending on the insurer. During that time the car sits, the tech moves to another job, and the customer doesn't know why their vehicle isn't done.
The existing auto body shop software products have API connections to the major estimating platforms. None of them have meaningfully automated the supplement workflow. The result is that shops handling 20 or more vehicles a week need a dedicated person for supplement administration — chasing approvals, managing adjuster callbacks, updating customers. That's a $50,000-per-year headcount solving a software problem.
This gap exists because the people who built these products understood the data structures but not the operational reality of getting a supplement approved at 4pm on a Friday when the adjuster is OOO until Monday. That's information that comes from running a shop, not from a user interview.
The workflow problem that lives in supplements
A supplement is a change to a pre-approved estimate. The information required to process one — damage photos, updated labor hours, a revised parts list — already exists in the estimating tool. Getting that information to the right insurer contact in the right format, tracking the approval status, and updating the job card when authorization comes back is a manual process in every product currently on the market.
The shops that manage this well have developed their own institutional knowledge: which insurers respond in 24 hours versus 72, which DRP partner needs the estimate formatted as a PDF versus submitted through a portal, which adjuster is reachable on the phone versus only through the portal message system. That knowledge, embedded into software, would cut the average supplement cycle by two or three days. Applied across a shop doing 80 jobs a month, that's material throughput improvement.
The product doesn't need to be smarter than the operators. It needs to capture what the best operators already know and make it executable by everyone in the shop, not just the person who's been there for 12 years.
What an operator-founder builds here that a developer doesn't
The vertical SaaS thesis applies cleanly to collision repair. The market is large enough to support a category-defining product. The workflow is complex enough that general-purpose tools don't work. The incumbents are old enough to have significant technical debt. And the buyers are concentrated enough that a founder with relationships in one metro area can get to 20 paying shops before spending anything on paid acquisition.
The product that collision shops actually need is not a new estimating tool. It's an operations platform that understands the repair lifecycle end-to-end: what needs to happen when, what information needs to move where, and which human decisions genuinely require human judgment versus which ones have been manual for 20 years because nobody bothered to automate them.
A founder who ran a collision shop for a decade has that product spec in their head. The constraint is not the product insight — it's the technical build and the funding to get to market at speed. Those are solvable problems with the right co-builder.
If you've spent years in collision repair and the broken workflow has been obvious to you, that operational knowledge is the unfair advantage. We build with operator founders who already know the problem. Tell us what you'd fix.