# Turn a workshop idea into your own diagnostic product. — SyntaForge Canonical: https://syntaforge.com/en/projects/automotive-diagnostics/ Language: en > This is a text rendering of the same public webpage. Use the canonical URL for citation. Private inquiry records and administrator data are never included. An over-shoulder view of a mechanic reading vehicle diagnostic data on a T9 wrist screen. Case study # Turn a workshop idea into your own diagnostic product. A founder with workshop experience brings OBD data, a wrist display and inspection records into one focused product. [Talk to us](https://syntaforge.com/en/contact/) A mechanic connecting an OBD adapter below the dashboard, with a compact T9 on the wrist. Case study Diagnostic-product founders ## The starting point. The founder has watched technicians move between vehicles and diagnostic equipment. They want selected readings at the wrist, but need help deciding how the adapter, supported vehicles, interface and records should work together. T9 · On the wrist ### The customer and the initial idea ### A product idea that starts beside the vehicle. This project starts with a founder who knows automotive repair and can speak to technicians about their daily work. They do not have a full electronics, mechanical and device-software team. The idea is specific: if the vehicle is right here, why keep walking back to another screen for a few readings? They want an OBD-linked wrist product under their own brand, starting with one common inspection. A technician would connect the adapter, check selected readings beside the vehicle and save a record. The founder needs a complete combination to try in workshops; the hardware form and software scope can be defined with us. ## The decisions we make together. An over-shoulder view of a mechanic reading vehicle diagnostic data on a T9 wrist screen. Case study ### Vehicle and adapter coverage Validate the actual vehicle protocols, supported readings and adapter connection for the intended service. A mechanic connecting an OBD adapter below the dashboard, with a compact T9 on the wrist. Case study ### Data with a clear status Show the source, refresh state and connection loss so an old reading is not mistaken for a current one. A mechanic saving a vehicle inspection record from the wearer-facing wrist screen. Case study ### A screen for the workshop Test viewing posture, controls, sleeves and gloves while the technician pauses to read. ### What we would define together We would work back from the target workshop and inspection: which vehicles, which adapter, which data and what update rate the task really needs. Vehicle and adapter provide the readings, the wrist display supports checking and confirmation, and an app or work-order system keeps the record. Connections, failure states and data ownership need clear decisions. An OBD adapter reads supported vehicle data and sends it to the T9 through the selected connection. The wrist interface shows a few relevant readings. Inspection records are then saved to the agreed app or work-order system. ## From definition to a pilot. Define the use case. Build the prototype. Try it with the team. Refine the first batch. A light worktable with product sketches, a T9 sample and a screenless band during a product discussion. Service illustration ### Define the use case. We would work back from the target workshop and inspection: which vehicles, which adapter, which data and what update rate the task really needs. Vehicle and adapter provide the readings, the wrist display supports checking and confirmation, and an app or work-order system keeps the record. Connections, failure states and data ownership need clear decisions. A T9 terminal with two right-side buttons resting on its strap beside a development laptop. Service illustration ### Build the first devices. The trial would use an agreed set of vehicles, an adapter and an inspection task. A small batch of complete kits could go to participating workshops. With the founder, we would review connection, reading and saving, including disconnects, stale-data warnings, glove use and record completeness. The trial is a way to find limits before widening the scope. A mechanic saving a vehicle inspection record from the wearer-facing wrist screen. Case study ### Try it. Plan the next batch. If the first task is validated, workshop feedback can guide what comes next. New vehicles, readings and backend connections need their own checks. The founder can then refine product positioning, instructions and support arrangements before discussing another batch or more workshops. ### Define a complete kit for the first trial. ### A kit with a clear support scope The agreed wrist device, adapter connection and device software, prepared for a selected vehicle group and inspection task. ### Readings and records that make sense Clear data sources, update times, disconnect states and inspection records, with app or work-order integration within the agreed scope. ### Evidence for the next version Workshop feedback and a documented compatibility scope to guide features, instructions and further batches. ### How the task would work - 01 ### Connect the adapter Use the selected vehicle and adapter setup to establish the data connection. - 02 ### Check the wrist screen Bring the screen toward the wearer and review the selected, supported readings. - 03 ### Save the inspection Store the readings with their time, vehicle reference and any technician notes. ### What the pilot should establish The first trial should validate the vehicle–adapter–wrist data path, show whether technicians find it useful for the chosen task and check record completeness. Those findings determine the next version and any wider vehicle scope. ## Have a product idea from the workshop? [Talk to us](https://syntaforge.com/en/contact/) [All applications](https://syntaforge.com/en/projects/) [Platform reference](https://syntaforge.com/en/platforms/vanguard-t9/) Functions, suitability and delivery scope are defined and validated for each project.