AI-Assisted Product Development Framework — Automotive Hardware + Software (v0.1)

2026-09-17 · Subhasis Behera, CEO & Chief Engineer, Veynqor

How to use this guide

This guide turns the way V-DRIVE, the V-DRIVE HAT, SARATHI/V-SHADOW and SIGNAL were built into a repeatable method for automotive hardware + software products. AI tools do the drafting, searching and scaffolding; the engineer makes the decisions and signs off at the points that can break hardware or hurt people.

• Who it is for: teams building an in-vehicle or on-technician device with an embedded side, a cloud side and, increasingly, an on-device AI model.
• How it is organized: 3 stages, 9 phases. Each phase has an exit gate; the next phase does not start until the gate is met.
• How to read a phase: every phase follows the fields in Phase template below. Lessons from real builds live in one register near the end, tagged by phase.
• Status: v0.1 is the high-level plan. Each phase gets step-level checklists and prompt templates in later revisions.

The method at a glance

Nine phases in three stages, each closed by an exit gate; V2 scope loops back to Phase 3.

Read left to right: nothing custom is built until the data path is proven on bought parts, and the enclosure is designed only after the electronics are locked.

Tool map

One tool drives each phase; the others feed it or take its output. Claude (chat app) is the thinking and writing tool, Claude Code the building tool, and Flux.ai and Onshape the domain CAD tools.

Cowork also serves as the per-project folder agent (briefs, runbooks, user guides assembled from working files), and Claude in Chrome captures dashboard screenshots for those guides.

Phase template

Every phase below is written to the same seven fields, so a client can compare phases and a consultant can audit progress.

1. Purpose and entry condition — what the phase proves and what must already be true.
2. Steps — in order, each small enough to finish in a session.
3. Driving tool and prompt pattern — which AI tool leads, and the way of prompting it that worked.
4. Human sign-offs — decisions never delegated to a tool: part orientation, safety behavior, anything that reaches a vehicle or a customer.
5. Artifacts — the files that exist when the phase is done.
6. Exit gate — the observable condition that opens the next phase.
7. Lessons — failure modes seen in real builds, kept in the register and tagged with the phase number.

v0.1 fills fields 1 to 6 at high level. Detailed planning adds step-level checklists and reusable prompt templates.

Stage 1 — Plan

Phase 1 — Define

Purpose: end with a one-page product brief the client can defend in two sentences: who pays, and for what pain. Entry condition: an idea and a target user.

Steps

1. Name the operator and the pain in their words (a fleet stranded by an OEM exit; a technician with both hands on the vehicle).
2. Run a competitive scan with Claude and web search: one table of incumbents by feature, price and gap.
3. Draw the product boundary: edge device, cloud ingest, analytics. Decide what is bought and what is built.
4. Set the product family naming convention (for example, a hardware prefix and software names).
5. Write the brief: user, pain, boundary, first customer, what V1 must prove.

Driving tool: Claude chat with web search. Prompt pattern: give Claude your background, the user and the pain first, then ask for the comparison table before the brief.

Human sign-offs: the thesis (who pays) and the product boundary.

Artifacts: one-page brief; competitive table.

Exit gate: brief reviewed and the first paying customer type named.

Phase 2 — Prove on off-the-shelf parts

Purpose: prove the whole data path on parts you can buy today, before any custom hardware exists. Entry condition: the Phase 1 brief and a vehicle you control.

Steps

1. Build a bought-parts rig: single-board computer or dev board plus a CAN interface, powered from the vehicle.
2. Have Claude write the capture and decode scripts (cantools, pandas, pyarrow), the upload to S3, and the Athena queries.
3. Stand up a minimal dashboard so real signals are visible, not just stored.
4. Drive and log: bus behavior, signal names, power draw, mounting and cable issues.
5. Write down what the rig taught you; this becomes input to the architecture.

Driving tool: Claude chat writing small scripts, kept in a GitHub repo from the first commit.

Human sign-offs: what "good enough" data looks like for the first customer.

Artifacts: working rig; first real dataset in the cloud; field notes.

Exit gate: real vehicle data flows end to end and can be viewed in a dashboard.

Phase 3 — Architect and specify

Purpose: turn the proven path into an architecture document, numbered requirements, a phased plan and an ordered parts list. Entry condition: Phase 2 gate met.

Steps

1. Write the architecture doc with Claude. Edge side: buffering, batch file format, connectivity state machine, offline storage, power and sleep, OTA. Cloud side: ingest via pre-signed URLs, decode, store, view.
2. Write requirements in shall-language with IDs (F-01, F-02 ...), tolerances and acceptance criteria. Load them into Jama or Polarion when the client needs traceability.
3. Build the phased plan with weekly milestones (for example: capture validated by week 2, end-to-end upload by week 3).
4. Select the platform dev-board-first: a cellular ESP32 module for a logger, a Jetson Orin class board for vision or voice. Compare candidates in one table (resolution, lighting, interfaces, ecosystem, power).
5. Produce the BOM with vendor part numbers, and verify the pin map against the vendor's source files, never the product page.

Driving tool: Claude chat with web search, output as a Claude Doc or .docx. Prompt pattern: architecture first, then requirements derived from it, then parts that satisfy the requirements.

Human sign-offs: platform choice; requirement priorities; the build order.

Artifacts: architecture doc; requirements list; phased plan; BOM; verified pin map.

Exit gate: documents reviewed, parts ordered, pin map verified against source.

Stage 2 — Build

Phase 4 — Software: embedded and cloud

Purpose: build the firmware and the cloud code in Claude Code, with the development framework in place before the first feature. Entry condition: architecture doc and dev board in hand.

Steps

1. Scaffold the repos with Claude Code. Firmware: ESP-IDF v5 project, custom partition table (dual OTA, NVS, spill storage), one module per concern, unit tests. Cloud: infrastructure as code, decoder Lambdas, API, frontend.
2. Write CLAUDE.md (what Claude Code may do unattended), RUNBOOK.md, and a smoke-test script that checks every endpoint. Git from the first file; configuration out of the code.
3. Implement module by module against the phased plan, with stubs for later phases and a test per module.
4. On-device AI (Jetson class): run a calibration eval harness on the bare model first, choose the model by score, freeze the version, and put the safety behaviors in deterministic code with self-tests, never in the prompt alone. Tag every eval run to its commit.
5. Where connectivity varies, build a dual backend: the local model is the floor that always works, the cloud API is the upgrade.

Driving tool: Claude Code in the repo, with VS Code + ESP-IDF extension for build, flash and monitor. Prompt pattern: point Claude Code at the architecture doc and CLAUDE.md, then ask for one module and its test at a time.

Human sign-offs: safety behaviors; anything that writes to production; the frozen model version.

Artifacts: firmware and cloud repos; CLAUDE.md and RUNBOOK.md; tests; eval results.

Exit gate: each module bench-validated, end-to-end upload proven, smoke tests green.

Phase 5 — Bench bring-up and integration

Purpose: get hardware and software running together on the bench, gated by verification steps anyone can repeat. Entry condition: Phase 4 modules exist; boards are on the bench.

Steps

1. Install the platform: OS or JetPack, toolchain, power mode, swap and storage. Record versions.
2. Bring up one peripheral at a time: USB serial, modem AT commands, GNSS, mic array with echo cancellation, audio routing, camera. Give Claude the log output and photos, not a description of them.
3. Write the runbook as numbered verification gates with a troubleshooting matrix.
4. Benchmark latency, throughput and memory; record each figure against the commit that produced it.
5. Run everything as services (systemd with restart), headless, with a remote control path such as a phone hotspot and a small web panel, plus SSH as the escape hatch.

Driving tool: Claude chat fed with logs, photos and datasheets; Claude Code for scripts and service units. Prompt pattern: one peripheral per thread, starting with the previous thread's runbook.

Human sign-offs: go/no-go on the full loop; the bench configuration that becomes the reference.

Artifacts: runbook with gates; benchmark table; service units; setup script.

Exit gate: the full loop runs unattended on the bench and survives a power cycle.

Phase 6 — Custom electronics

Purpose: replace the stack of dev boards with a custom board in the lowest-risk shape: a mezzanine (HAT) that stacks on the proven vendor module. Entry condition: Phase 5 gate met; the firmware pin map is final.

Steps

1. Scope the board. Radio, modem and MCU stay on the vendor module; your board carries only power, transceivers, protection and connectors. Prototype boards skip automotive-grade part certification.
2. Have Claude write the design package: component list with LCSC part numbers (Basic parts wherever possible), netlist, layout constraints, and DNP decisions such as bus termination.
3. Feed Flux.ai staged prompts: master prompt for the schematic, then footprints, then layout, then JLCPCB export. After auto-layout, hand-clean the power path and keep differential pairs short.
4. Run the pre-order checklist: DRC clean, full Gerber layer set, BOM and pick-and-place with verified part numbers, both assembly sides selected, every polarized part checked by net rather than silkscreen.
5. Work the fab's DFM review in the same thread; answer orientation questions with annotated images that Claude generates.
6. Bench test the delivered boards and log every V2 fix (clearance, missing parts, orientation).

Driving tool: Claude for the design package and prompts; Flux.ai copilot for schematic, layout and export; JLCPCB for fab, assembly and DFM. Prompt pattern: front-load the whole design into one master prompt, then stage the rest one step per message.

Human sign-offs: part orientation and polarity; the assembly order configuration; the decision to ship the router's layout.

Artifacts: design package; Flux project; Gerbers, BOM, pick-and-place; order record; bench test log.

Exit gate: boards pass DFM, arrive fully assembled and pass the bench test.

Phase 7 — Enclosure

Purpose: house the locked electronics in a printable, serviceable enclosure. Entry condition: Phase 6 boards tested; the enclosure follows the boards, never the reverse.

Steps

1. Gather STEP or STL files for every board, connector and antenna; caliper the real boards and note where they differ from the published models.
2. Build a 1:1 paper or cardboard mockup with the real boards inside. Check ports, cable exits, LED visibility and SIM access before any CAD.
3. Model in Onshape as the system of record, STEP AP242 in and out. Use AI CAD plugins for concept sketches only; treat their output as a starting point to refine by hand.
4. If the CAD is outsourced, issue a formal design brief: shall-requirements with IDs, a tolerance table, DFM rules for the print process (SLS/MJF PA12 wall thickness, powder escape holes), CAD workmanship rules, acceptance criteria, three review checkpoints and a risk register.
5. Choose process and vendor: FDM for fit checks, SLS or MJF for batches; compare JLCPCB, PCBWay and Xometry on finish consistency and price for the batch size.
6. Print, fit with cables routed, revise once.

Driving tool: Claude for the brief and DFM rules; Onshape for the model; the print vendor's DFM check. Prompt pattern: give Claude the STEP inventory and the mockup findings, then ask for the brief.

Human sign-offs: process choice; brief acceptance; the fit check.

Artifacts: STEP files; 2D drawing PDF; fastener and insert BOM; design brief.

Exit gate: the printed enclosure fits the real boards with cables routed and every port reachable.

Stage 3 — Ship

Phase 8 — Field pilot

Purpose: put units with a real operator and turn the returned data into one finding the customer cares about. Entry condition: a bench-proven unit in its enclosure.

Steps

1. Pick a pilot with a real fleet problem and agree in writing what success looks like.
2. Install, then verify data flow on day one before leaving the site.
3. Build the decode layer for that fleet: extract signal definitions from the OEM's sources into DBC files with Claude Code.
4. Investigate anomalies forensically with Claude (for example, a bus voltage collapse that raised no diagnostic code) and write the finding up for the customer.
5. Log feedback, gaps and feature requests into the roadmap sheet.

Driving tool: Claude chat for analysis; Claude Code for decoders and DBC extraction; the telemetry dashboard for the customer view.

Human sign-offs: what goes to the customer and in what words.

Artifacts: pilot dataset; DBC files; finding report; roadmap entries.

Exit gate: pilot data flowing for the agreed period plus one documented finding the customer acted on.

Phase 9 — Learn and V2

Purpose: close the loop: lessons into the register, scope into V2, and a date on which the build stops. Entry condition: pilot findings in hand.

Steps

1. Review every phase's bench and field logs; add each failure mode and its prevention to the register.
2. Update the enhancement roadmap sheet with current, V2 and V3 columns, each item tied to a customer request or a lesson.
3. Time-box the next build: a hard code-freeze date and a dress rehearsal with the full rig before any demo or deployment.
4. Write the V2 brief and return to Phase 3 with it.

Driving tool: Claude for the register and roadmap; Cowork to assemble the review from scattered notes and logs in the project folder.

Human sign-offs: the V2 scope and the freeze date.

Artifacts: updated lessons register; roadmap sheet; V2 brief.

Exit gate: V2 scope agreed and dated.

Cross-cutting practices

Seven habits hold across every phase; they are what keeps AI-assisted work reproducible.

• Continuity between sessions. Keep a project folder with the architecture doc, CLAUDE.md, runbooks and prior threads; start each session by having Claude read the previous one before asking anything new.
• Version control everything. Code, prompts, briefs, eval question sets and eval results, each tagged to the commit it came from.
• Prompt with evidence. Logs, photos, datasheets and vendor source files, not descriptions of them. Front-load the whole context in one master prompt, then stage the steps.
• Human sign-offs at physical points. Orientation, polarity, order configuration, safety behavior, anything that reaches a vehicle or a customer.
• Outsource with formal briefs. Numbered requirements, acceptance criteria, checkpoints and file-format handoffs, so the work is owned in your tools afterwards.
• Dev board first, custom board second, enclosure last. Never touch radio or MCU design on a first board; never design a shell around electronics that may still move.
• Time-box. A hard freeze date and a dress rehearsal beat one more feature.

Failure modes and checklists

Every row happened on a real build; the prevention column is the checklist item that stops it recurring. This register is the single home for lessons, tagged by phase.

Engagement packaging

The phases group into three engagements plus a coaching format; durations are first estimates from the V-DRIVE and SARATHI timelines and need review.

The coaching format is where the training material and the recorded live sessions come in.

Training delivery (to be decided)

Recommendation: keep this guide as the single source and add two layers, presentation and live-session capture, designed so the AI reads almost nothing in real time and is called only at checkpoints.

Presenting the material

• This Claude Doc as the living guide: shared with the client, comments in place, exported to PDF or Word for the engagement record.
• One slide deck per phase generated from the doc for workshops; the phase template is the slide skeleton.
• A per-client project folder run with Cowork holding the checklists, briefs and session logs; Claude in Chrome captures dashboard screenshots for the client's user guide.

Recording and guiding live sessions with minimal tokens

This is the SARATHI pattern applied to consulting: a local floor that costs nothing per minute, and the cloud model as the upgrade.

1. Capture locally at zero token cost: whisper.cpp for speech (already on the bench laptop), the Claude Code session transcript for terminal work, and a screen recording for hands-on work.
2. Register each session as one markdown log in the client's folder: date, phase, gate, transcript, files touched, decisions taken.
3. Guide at checkpoints, not continuously. At each exit gate, or on a spoken trigger word, send the session log plus the relevant phase section to Claude. Use the smallest model that passes a short eval on your own sessions, and keep the framework text as cached context so each call pays mainly for the new transcript.
4. Let a deterministic layer decide when the model is called (keyword and state rules, like the safety interceptor on SARATHI); the model never listens to the whole session.

Decision pending: (a) a self-built pipeline on the existing stack (whisper.cpp, a small router script, the Claude API), or (b) an off-the-shelf meeting recorder for capture with Claude only at checkpoints. Evaluate both against one recorded session before choosing.

Verify caching and session-transcript details against the Claude API docs and Claude Code docs when this layer is built.

Next steps

Detailed planning goes phase by phase, starting where the tool-specific know-how is densest.

• Review this v0.1: phase list, template fields, tool map, engagement durations.
• Phase 3 in detail: architecture doc template, requirements format, parts-comparison table, pin-map verification checklist.
• Phase 6 in detail: design-package template, staged Flux.ai prompt set, pre-order and DFM checklists.
• Phase 4 in detail: CLAUDE.md and RUNBOOK.md templates, smoke-test pattern, eval-harness procedure for on-device models.
• Phase 7 in detail: STEP inventory, mockup procedure, outsourced design-brief template, print-process DFM rules.
• Phases 1, 2, 5, 8 and 9 in detail.
• Expand the failure-modes register from bench and field logs.
• Decide the training-delivery method and prototype the session-capture pipeline against one recorded session.