AI hardware development includes defining a device’s requirements, designing its electronics and physical structure, implementing embedded behavior, connecting the AI workflow, and producing evidence that the system meets its agreed purpose. For a CTO or product manager, the useful question is which engineering outputs a project actually includes: schematics, PCB layouts, firmware, interfaces, prototype units, test records, and production documentation. The scope changes when an existing platform is reused or when the customer supplies the app, model, or cloud service. A clear scope therefore connects every requested capability to an owner, a deliverable, an acceptance method, and the inputs needed from another team.
Start with outputs you can review
A proposal that lists electronics, firmware, and AI integration still leaves substantial room for interpretation. A buyer may expect editable design files while a supplier has priced only assembled prototypes. Both parties may assume the other will create the test application. Those differences should be resolved before the first build is commissioned.
Use four questions to examine each work item:
- What artifact or working behavior will be delivered?
- Who provides the information needed to create it?
- How will the buyer decide whether it is complete?
- What related work requires a separate agreement?
The answers give commercial teams a way to compare proposals and give engineers a shared definition of completion. They also distinguish an estimate based on known requirements from one that depends on unresolved assumptions.
Electronics and mechanical design need separate deliverables
Electronics work can include component selection, circuit design, board layout, power architecture, connectors, and assembly documentation. Spell out which outputs are included. A schematic represents circuit connections; it is a different deliverable from the physical board layout or the assembled board used in a prototype.
For example, KiCad’s schematic editor supports electrical rules checking and bill-of-materials generation. These functions illustrate why a schematic project contains useful engineering information beyond a presentation drawing. KiCad schematic documentation
Board layout needs its own review criteria. KiCad’s PCB checker evaluates configured design rules and connections, with an optional comparison between board and schematic. The rules must suit the selected manufacturing process. A clean checker result is therefore one review artifact; the project still needs its agreed physical and functional checks. KiCad PCB design checks
Mechanical scope should name the expected CAD files, enclosure materials under consideration, board mounting, control locations, cable access, and assembly approach. Appearance models, functional housings, and manufacturing drawings serve different decisions. Request each only when the project requires it, with clear revision and approval responsibilities.
A product manager reviewing a sample should be able to locate the drawings behind it. If a button moves or a connector changes, the relevant records should explain which board and enclosure versions remain compatible.
Firmware connects the design to device behavior
Firmware scope should describe observable states: starting, waiting, acquiring input, transferring data, reporting failure, recovering, and shutting down. Also name the hardware revision, build configuration, supported peripherals, and programming method.
The relationship between board configuration and firmware is concrete. Zephyr uses devicetree nodes and properties to describe hardware and its connections, including peripherals on a bus. A hardware substitution can therefore require configuration work as well as a physical component change. Zephyr devicetree documentation
For procurement purposes, request a written answer on:
- Whether source files, binaries, and build instructions are included.
- Which drivers and operating-system components are reused.
- How the delivered firmware is matched to board revisions.
- Which diagnostic outputs are available during integration.
- Who handles defects discovered after sample acceptance.
These items do not require every buyer to become an embedded developer. They make future debugging and maintenance understandable. The ownership, access, and licensing arrangements should be agreed with the relevant parties.
Define what “AI integration” means in this project
AI integration can cover several different tasks: preparing sensor input, connecting to a remote service, adapting a model for an embedded runtime, interpreting model output, and presenting a useful response. List the tasks separately and identify the supplied assets.
A customer who supplies a working desktop model has not necessarily supplied a deployable device model. Google’s LiteRT for Microcontrollers documentation describes model conversion, supported-operation constraints, and device-side inference. It also states that on-device training is unsupported in that runtime. These are platform-specific examples of the compatibility questions an integration scope must answer. LiteRT for Microcontrollers
For a connected device, the main work may instead be capturing suitable input, transferring it, handling service responses, and showing failures clearly. Ask who supplies the API, credentials, sample payloads, output rules, and evaluation examples. “AI development included” is too broad to settle those responsibilities.
Acceptance should connect AI behavior to the intended task. A model can return a well-formed response while the user’s workflow still fails because the wrong input was captured or the result arrived after the user had moved on.
A scope matrix for an engineering discussion
The following matrix is an illustrative planning tool for a software company commissioning a connected device. It is not a Yosiya customer project, quotation, or standard service package. Adapt the rows before requesting a proposal.
| Work package | Proposed engineering output | Buyer input | Acceptance evidence to agree |
|---|---|---|---|
| Input electronics | Circuit and board design for the selected sensor | Required input conditions and sensor constraints | Review record and captured input samples |
| Mechanical structure | Housing and mounting design | Use position, controls, access needs | Fit review against a defined board revision |
| Device behavior | Firmware for acquisition and status reporting | User states and failure priorities | Demonstration using named test scenarios |
| Service connection | Implemented data interface | API specification and sandbox access | Matched request, response, and error records |
| AI behavior | Agreed preprocessing or model integration work | Model or service, examples, evaluation rules | Results on an approved evaluation set |
| Prototype build | Identified sample configuration | Approval of temporary substitutions | Unit list, version record, and known limitations |
| Production preparation | Agreed build and inspection package | Release decision and product requirements | Review of the specified handoff files |
Notice that the matrix describes evidence without promising a performance number. The team must choose any numerical threshold from the actual use case and feasibility work. Adding a convenient benchmark to a proposal does not make it an appropriate acceptance criterion.
Include recovery and maintenance in the boundary
If a device is expected to receive updates, the scope should include how new firmware is installed, checked, approved, and recovered when a problem appears. Identify what can be updated remotely and what requires physical access.
Espressif’s ESP-IDF documentation provides a concrete example: its optional application rollback process can return to a previous working application when a new one is not confirmed as operational. The implementation has configuration and partition requirements. A generic promise of update support does not specify that behavior. ESP-IDF update and rollback documentation
Ask separately about the update mechanism and the service that operates it. Hosting files, approving releases, managing device groups, answering support requests, and maintaining compatible apps may belong to different teams. Make those boundaries visible while the device is still being defined.
Turn an unclear line item into a reviewable one
Consider this fictional proposal line: “Provide an AI-enabled sample with app connectivity.” A more useful scope entry would read:
Deliver an identified prototype that captures the agreed input, transfers a sample through the buyer’s test interface, and displays the agreed success or failure state. Include the firmware build identifier, interface description, test procedure, and a list of temporary components. The buyer supplies the service endpoint and example responses.
That entry still needs project-specific conditions and acceptance thresholds. Its value is that both teams can see the work and its dependencies. They can then decide whether enclosure refinement, production test fixtures, app distribution, or service operation belong in this engagement.
For changes, use a short impact record: requested change, affected outputs, required new evidence, responsible reviewers, and revised assumptions. A new microphone, for example, should trigger a review of the input path and the tests that depend on it. Record the conclusion even when the team decides no redesign is necessary.
FAQ
Can we commission only the electronics portion?
Yes, if the remaining work has named owners and the interfaces are sufficiently defined. Supply mechanical constraints, device behavior, and the receiving team’s file requirements. Confirm who performs integration when the board arrives and who resolves problems that span disciplines.
Are editable design files always part of development?
Their inclusion depends on the agreement. Ask which native project files, libraries, manufacturing exports, build instructions, and licenses are delivered. Also establish what the buyer may modify and which third-party assets have separate conditions.
Does a development fee include tooling or sample parts?
That cannot be assumed. Ask the proposal to identify engineering labor, purchased components, prototype fabrication, tooling, fixtures, outside services, and shipping as applicable. The purpose is to understand scope and dependencies before comparing totals.
How should we compare proposals with different boundaries?
Put their deliverables into the same scope matrix. Mark included, customer-supplied, separately quoted, and unresolved items. Compare the acceptance evidence as well as the output: receiving a board and receiving a tested integrated prototype are different commitments.
What should happen when the customer changes the model?
Review the changed input, output, runtime, and resource assumptions before accepting the replacement. Determine which device behaviors and evaluation records must be revisited. A model revision should have a named approval owner even when the electronics remain physically identical.
Request a capability overview tied to your scope
Yosiya lists hardware engineering, prototyping, and OEM/ODM capabilities on its company page. Prepare the work packages you want to commission and the assets your own team will supply. Then request a capability overview mapped to those needs, including proposed deliverables, dependencies, and acceptance evidence.
