Skip to content

Vehicle inspection workspace

PAUSED

The hard part was never the case management.

An unfinished workspace for a vehicle-accident inspector, built around the manual work before legacy systems got in the way.

Independent project · Product, engineering & design

Why I built it

My father works as a vehicle-accident inspector for insurance companies. A case can mean documents, people, vehicles, notes, costs, reports and a surprising amount of finding the same information in more than one place.

The manual work was obvious from the outside: the shape of a case was clear, but the working context around it was scattered. I wanted to see what a calmer workspace could look like if it put the case, its evidence and the next piece of work together.

What I built

I started with the ordinary parts of the job, rather than a grand system. There was a searchable case list, a two-step flow for opening a case, and a workspace for the information someone needs while working through it.

A fictional vehicle-inspection case dashboard with filters for status, case type and event type, and seven invented cases in a table.
The case list: a place to find the work before opening another file.

Within a case, the app linked the people, vehicles, documents and financial context together. The point was not to make a prettier record. It was to make the relationships between the bits of work visible while they were still useful.

A fictional inspection case workspace showing general information, participants, vehicles, recent documents and financial totals for a collision case.
A case workspace kept the working context in one place.

Documents were the part I was most curious about. The prototype supported upload, OCR, editing the extracted text, download and deletion. It also made that text available to the app’s knowledge-base work, so a document could become something more useful than a file sitting in a folder.

A fictional OCR preview open over an inspection document list, showing an invented witness statement with editable extracted text.
OCR was there to make the document usable, not just to tick an AI box.

There was also a lightweight task board. It was deliberately plain: the aim was to make the next action obvious, not to turn an inspection into a project-management ceremony.

A fictional task board with planned, in-progress and completed columns for inspection work.
The work around a case mattered as much as the record of the case itself.

Where it stopped making sense

The prototype made the workflow clearer. It did not solve the part that mattered most: it would still have to live alongside the very old systems used by the companies he works with.

We looked at integration and at using a separate tool side by side. Neither was a comfortable answer. Re-entering information or keeping two systems in sync would simply move the manual work somewhere else, and the integration work was beginning to look like the actual product.

So I paused the app. That was not a failure of the interface; it was the answer to the original question.

We did keep going in a different direction, experimenting directly with AI in a more robust, secure setup. That work is separate from this unfinished application, and this page is not a claim that the prototype became a deployed workflow.

What I learned

The workflow is bigger than the screen

The case workspace was useful because it reflected the work around a case, not because it collected lots of fields. But the real workflow also included systems outside the workspace. Ignoring those boundaries would have made the product look more complete than it was.

Integration is a product decision

It is tempting to leave integration for later because the product can be demonstrated without it. Here, the question of where information starts, moves and has to be entered again was the product question from the beginning.

A prototype can still give a useful answer

The app was unfinished, but it made the trade-off concrete. That was enough to stop building the wrong thing and focus the next experiments on the work that might actually fit.

Built with

Next.js · React · TypeScript · FastAPI · PostgreSQL · OCR · vector search