Two Repair Platforms, Neither One Open Source

The brief was one line. Take a look at repairflow.dev and Repair Ally, the open source AI platform, go through them thoroughly, and say what would make our system better.

Two things in that sentence were wrong, and correcting them first is the whole point of this article.

The premise check

repairflow.dev is not an auto repair platform. It is a personal electric vehicle repair shop in Marietta, Georgia. Onewheels, electric bikes, electric scooters. It does sell shop software, but that software is for device and electronics repair, not for cars.

Neither one is open source. Repair Ally is a commercial product of Honest Technologies, Inc. RepairFlow's software is a paid product too. Nothing about either is forkable, readable, or licensed for reuse.

The genuinely open projects in this space are OpenAuto and OpenRepairPlatform. If what you want is code you can actually take, those are the two to start with.

This distinction gets blurry fast when you are moving quickly. Open source is a license, not a vibe. A product with a free tier, a public API and a developer looking domain is still somebody's product. You can learn from it, and you should. You cannot fork it.

So we studied the output.

Run the funnel with a real case

The useful move was not reading their marketing pages. It was putting a real car through the whole thing.

A 2020 Honda Accord, rough idle, 40,000 miles, a Scottsdale zip code. Real symptom, real mileage, real climate. What came back was worth more than a week of reading competitor screenshots, and doing this is worth your afternoon whatever you are building. Their landing page tells you what they want you to think. Their funnel tells you what they built.

The one thing that changed our mind

Every test Repair Ally produced carried a field labeled what this confirms or rules out, and every test was marked passed or failed with a free text note on the failure.

That single shape is better than what we had, and it was not close.

Our technician typed prose into a box called "what you found," and the quote drafter read that prose. It works, roughly. What it cannot ever produce is the sentence that matters when a customer comes back angry six weeks later.

We ruled out vacuum leaks and fuel trim before we sold you a coil.

You can only say that if somebody recorded that you did. Prose does not record it. Pass and fail against a named test does.

On their sample the technician had written "misfire followed the coil when swapping between cylinders" against a failed test. That one line, plus the state of the tests around it, is a defensible diagnosis. A paragraph in a notes field is a story.

The rest, ranked

Their plan is ordered by probability times ease of testing. Not just by how likely a cause is, but cheapest to eliminate first. Ours ordered nothing at all.

Every test carries its own time, difficulty and tool list, with a consolidated tool list up front. A technician knows before starting whether this is twenty minutes or ninety.

Two densities of the same content. A guided walkthrough, one step at a time, or an expert summary on a single page. That is the same split we had just arrived at for our learning pages, reached from a completely different direction in the same week. When two unrelated products in your sector both solve a problem the same way, that is a signal.

The diagnosis is context aware. It cited forty thousand miles in a hot, dusty zip code and pulled manufacturer bulletins for carbon buildup. We hold mileage, zip code and climate on every job and our drafter used none of it.

The lead capture is placed with real cunning. A "not beginner friendly, find a pro" link sits on the medium difficulty test. That is a lead captured at the exact moment somebody has proven to themselves that the job is beyond them, which is the highest intent moment in the whole industry.

That last one is not a feature note, it is a strategy note. They court repair chains and marketplaces and they publish an API. Anyone selling the same leads is either their best partner or their competitor, and it is worth deciding which before they decide for you.

What we actually shipped

The diagnostic step is tests now.

Each test is a card carrying what it confirms or rules out, minutes, difficulty, and a verdict of passed or found the fault. Tapping the same verdict twice clears a mistap, because technicians work on tablets with dirty hands. A failed test asks what it showed. The desk gets one built line back, reading found this, ruled out that.

One implementation note, because it is the sort of shortcut that usually rots. The test data is stored fenced inside the job's notes field rather than in its own table, so the change could ship without waiting on a database migration. Two functions are the only code in the system that knows this. Moving it to a real table later is a two function change instead of an archaeology project.

That is the difference between a shortcut and debt. A shortcut has exactly one door.

The lessons

Check the premise before you build on it. Two facts in a one line brief were wrong. If we had started from "it is open source" we would have spent an afternoon hunting for a repository that does not exist.

Run the competitor's product with your own real data. Not a demo case, not a screenshot tour. A real case with a real symptom, because the edges only show up when the inputs are awkward.

Learn the structure, write your own words. A verdict recorded against a named test is a structural idea, and structural ideas are how a whole trade gets better at something. The wording of their tests is theirs and stays theirs.

Notice when the same answer arrives twice. Two densities of one piece of content showed up in an eLearning tool and in a diagnostic tool in the same week. That is not a coincidence, that is a solved problem, and you can stop designing it yourself.