Build hardware with intent.

Physical products are not merely collections of CAD files, schematics, source code, spreadsheets, and manufacturing documents. They are connected systems of intent, constraints, decisions, interfaces, artifacts, and evidence. When those relationships are scattered across separate tools and people’s memories, every revision creates a reconciliation problem.

Protobench is my effort to create a coherent, inspectable workbench for that entire reality. The goal is to help founders, small hardware teams, product studios, labs, and design technologists take a physical-product idea from intent to a coordinated project that can be explored, changed, validated, and handed off with confidence.

The vision

Protobench is not a “hardware from one prompt” generator. It is a living product-development environment where the active mechanical model, electronics, firmware contracts, requirements, component data, validation results, decisions, and manufacturing outputs remain connected as the project evolves.

An intelligent collaborator called ProtoAgent helps interpret goals, surface missing information, propose bounded options, prepare changes, explain consequences, and maintain continuity. The visual artifact remains primary: users inspect, select, measure, compare, and understand the product directly instead of supervising engineering through a text-only chat or a dashboard of agent activity.

The problem: the reconciliation tax

A seemingly small change—moving a connector, changing a board outline, reducing an enclosure, replacing a component, or revising a power target—can affect mechanical clearances, mounting features, cable paths, pin maps, firmware assumptions, the BOM, validation evidence, and release files. Today, those consequences are usually reconstructed manually after the change.

Protobench is designed to make that dependency chain explicit before work is committed. The product’s defining unit is not a generated asset; it is a consequence-aware project change.

One consequence-aware change loop

1 — State the intent and must-preserve constraints.

2 — Select the exact project scope and current revision.

3 — Clarify unknowns and compare bounded options.

4 — Preview mechanical, electrical, firmware, BOM, and validation consequences.

5 — Inspect semantic, spatial, and file-level diffs before mutation.

6 — Approve, revise, reject, branch, or cancel the proposal.

7 — Apply only the approved authoritative changes.

8 — Run the affected checks and preserve evidence, rationale, and recovery.

This turns iteration into a traceable sequence from intent to evidence rather than a chain of disconnected edits.

ProtoAgent and ProtoGraph

ProtoAgent is the user-facing collaborator and control layer. It can explain, investigate, propose, prepare, execute approved work, and monitor for drift. It does not silently own consequential engineering decisions.

ProtoGraph is the project’s living map: requirements, parts, interfaces, artifacts, assumptions, risks, decisions, validation runs, and revisions retain stable identity and explicit relationships. When something changes upstream, the system can show what downstream evidence is now stale and why.

The first proving ground: PCB-in-enclosure products

The first production focus is a connected device with a PCB, enclosure, connectors, power constraints, firmware interfaces, validation, and a manufacturing handoff. This is narrow enough to prove rigor and broad enough to expose the real coordination failures that make hardware iteration expensive.

A representative transaction is deliberately concrete: select a USB-C connector, request a position or opening change, preview the enclosure and board consequences, inspect the diff, run fit and interface checks, approve the scoped edit, and produce reopenable evidence for the resulting revision. The workflow is the wedge; it is not the long-term limit of the product.

Human authority, honest status, and local ownership

Protobench separates automated checks, AI interpretation, and human judgment. Passed, failed, warning, unknown, stale, skipped, and not-run states must remain distinct. A convincing render or fluent explanation never becomes engineering proof by itself.

Material changes remain reviewable, attributable, reversible, and recoverable. Projects are intended to be local-first, readable, portable, and interoperable so the user’s product truth is not trapped inside a model transcript or an opaque cloud database.

Where the product is now

Protobench is currently a founder-led product-development effort, not a broadly released platform. The product thesis, interaction model, project system, visual language, requirements, validation philosophy, launch boundary, and go-to-market direction are defined. Interface prototypes and technical workflows have established meaningful feasibility, while the work now is to consolidate them into one coherent, dependable product.

My current development focus is:

• Proving one complete PCB-in-enclosure change transaction end to end.

• Making the CAD-grade viewport and active artifact the primary workspace.

• Hardening traceability, stale-state behavior, validation, rollback, and portable evidence.

• Turning the current product system into a focused design-partner experience.

• Testing the workflow on external projects before claiming broad product generality.

The startup direction

Protobench is in founder-led R&D and early customer-discovery mode. The near-term goal is not a wide feature launch. It is to work closely with a small number of hardware founders and compact engineering teams, complete real cross-domain revisions, observe where the workflow fails, and earn evidence of repeated use and willingness to pay.

The initial commercial focus is connected physical prototypes—sensors, embedded devices, wearables, robotics modules, instruments, and other PCB-in-enclosure products—where mechanical, electrical, firmware, sourcing, and manufacturing assumptions move together but are currently managed apart.

The long-term goal

I want Protobench to make hardware development feel as coherent, inspectable, and iterative as a well-run software project without pretending that physical engineering is software. The long-term product is a workbench where intent survives implementation, consequences appear before commitment, evidence travels with every revision, and teams can move faster without losing engineering truth.

Looking for design partners

If you are building connected hardware and routinely lose time reconciling enclosure, PCB, firmware, BOM, validation, and handoff changes, I would like to learn from your project. Contact me through the portfolio contact page to discuss a design-partner workflow.