Custom AI devices can start from an existing product platform, a compute module with a new carrier board, or a new board-level design. Adapting a platform is a strong candidate when its physical behavior and software access already fit the intended experience. A new design becomes worth evaluating when a necessary requirement conflicts with that baseline, such as sensor placement, physical dimensions, interfaces, or power architecture. The choice should follow the requirements that make the product useful and distinctive. Product leaders need to compare the work each route preserves, the constraints it introduces, and the evidence needed before committing to production.
Define what the product cannot compromise
Begin with the few requirements whose failure would invalidate the proposition. These may concern the way the device is worn or mounted, the input it captures, the permitted data path, the response a user needs, or the relationship with an existing software service. Describe them as observable behavior rather than component preferences.
For example, “the user can complete the task without a phone connection” is a requirement to investigate. “Use a larger processor” is a proposed solution. Keeping those separate makes it possible to compare genuinely different architectures against the same need.
An initial route review should establish:
- Which requirements are essential for the first release.
- Which existing assets the team can provide and has permission to use.
- Which platform restrictions would undermine the intended experience.
- Which unknowns require a technical demonstration before any route is selected.
A product team can bring this comparison to an engineering partner. Yosiya lists custom PCBA prototyping and hardware engineering among its capabilities; a proposed route still needs project-specific review.
There are three practical starting points
“Existing platform versus from scratch” can hide a useful middle route. Reusing a compute module while creating a carrier board preserves some electronics and software infrastructure while allowing selected interfaces and physical connections to change.
A carrier board connects a module to the power supply and peripherals needed by the product. Raspberry Pi’s Compute Module documentation describes its modules and IO boards, including the use of an IO board as a reference for a custom carrier. That is an example of modular design, not a recommendation that every AI device should use Raspberry Pi.
| Starting point | What may be reused | Where the team gains flexibility | Main questions to resolve |
|---|---|---|---|
| Existing device platform | Board, enclosure, firmware baseline, and supported accessories | Branding, supported options, and available integration points | Does the platform satisfy the essential workflow without extensive exceptions? |
| Module plus custom carrier | Compute module and relevant vendor software support | Required connectors, peripherals, board arrangement, and enclosure integration | Can the module’s interfaces, power needs, and physical form serve the product? |
| New board-level design | Selected components, reference circuits, libraries, and external services | Electronics architecture and component arrangement within project constraints | Does the value of the required differences justify the additional design and validation work? |
Even a new board rarely means inventing every technology. A project can reuse processors, radio modules, software libraries, and a trained model. Make the reuse boundary explicit so “custom” describes the delivered design rather than an assumption of unlimited ownership or freedom.
Compare the work left to do
An existing platform is attractive when it preserves work that your project would otherwise need. Confirm what that preserved work actually covers: documented interfaces, relevant sample behavior, production files, test methods, or a maintained software baseline. A supplier’s familiarity with a design is useful context, but it does not replace evidence that the intended configuration meets your requirements.
A new design changes the burden of proof. The team must establish which circuits, layout choices, mechanical arrangements, and software configurations require validation. It may gain a closer fit to the product while taking responsibility for more decisions. That can be justified, but it should be visible in the project comparison.
Separate the remaining work into three categories: reusable without modification, reusable after evaluation, and newly developed. Apply those categories to hardware, firmware, the app, the AI workflow, and production preparation. This exposes situations where a nominal platform adaptation contains enough changes to behave like a new development project.
For procurement, ask both routes to quote against the same user requirements. Compare engineering deliverables and recurring obligations alongside unit pricing. A low entry quote is hard to assess if software integration, fixtures, or ongoing service arrangements are outside its scope.
Test software portability before choosing the board
Having a working model file does not settle the hardware route. Establish which runtime, operators, accelerator libraries, and software versions the intended implementation uses. Then run representative inputs through a candidate system and inspect the complete result, including preprocessing and output handling.
ONNX Runtime’s execution provider documentation explains that hardware acceleration is provided through specific libraries and that supported parts of a model can be assigned to an execution provider. A common model format therefore does not establish identical execution or performance on every device.
For a route comparison, request the same evidence from each candidate: successful execution of the relevant model, identified acceleration paths, memory behavior, response under sustained use, and the handling of unsupported operations. Record the exact software build used. A desktop demonstration is a starting asset, not a measurement for the proposed embedded configuration.
Software access also affects future choices. If the product depends on a supplier-controlled app or backend, identify what can be changed and what happens if that dependency changes. A custom circuit board does not automatically give the brand control of those services.
Use development hardware for the decision it can support
Development kits can help a team explore software and interfaces before a final board exists. Their role should be described accurately in the project plan. NVIDIA’s Jetson FAQ distinguishes developer kits used for development and testing from Jetson modules intended for production deployment. This is a platform-specific example of why the demonstration hardware and the shipping configuration need separate review.
When a supplier demonstrates a workflow, ask what changes between that setup and the proposed product. Those differences may include the carrier, power source, cooling, sensors, enclosure, or software image. Record which test results will need to be repeated after the transition.
For either route, preserve the learning from the prototype: input samples, setup notes, failure observations, configuration identifiers, and test scripts where deliverable. The asset you want is a reproducible decision, not only a successful demonstration video.
Three illustrative decisions
The following scenarios are hypothetical planning examples. They do not describe completed Yosiya projects or promise a particular architecture.
A brand adds a dedicated accessory to an existing software workflow. Its differentiation is onboarding, task guidance, and the final report. An available device already provides the required input and physical interaction. Platform customization is a reasonable first route to investigate, provided the team can access the required interfaces and document service responsibilities. A new board adds little value if it does not improve the essential experience.
A field product needs a specific connector arrangement. A compute module can run the intended workload, but the standard development board is unsuitable for installation. A custom carrier and enclosure may be worth comparing with a finished industrial platform. The review should focus on interfaces, mounting, power, and environmental requirements rather than treating the module as a finished product.
A wearable concept depends on a tightly constrained shape. The intended sensor position and internal arrangement cannot be accommodated by the platforms reviewed. A new design may be appropriate if those physical constraints are essential and technically achievable. The team should first test the sensing and interaction assumptions, then decide whether the resulting value supports the engineering commitment.
The decision in each scenario follows a requirement that matters to the buyer. “Our own device” is too broad to choose an architecture; a defined user benefit gives the comparison a testable purpose.
Include the product’s expected service life
Consider the period over which units will be sold, maintained, and replaced. Ask how platform revisions and component changes are communicated, how software builds are maintained, and what happens when a component reaches the end of its availability.
As one example, NVIDIA publishes module lifecycle information and product-change notification guidance. Its page also distinguishes the lifecycle treatment of modules and developer kits. Check the relevant vendor’s current documentation for the actual proposed components; do not transfer one supplier’s policy to another platform.
A route comparison should therefore include the effort of keeping the product supportable. Reusing a maintained platform can be valuable, but its update policy must fit the deployment. A new design may offer control over selected parts while leaving dependencies on processor vendors, operating systems, or external AI services.
Ask for a decision package
Before approving either route, request:
- A requirements comparison showing pass, limitation, or untested status for each essential requirement.
- The exact reused assets and the rights to use and modify them.
- A list of new engineering work and its expected deliverables.
- The critical assumptions, proposed experiments, and decision owners.
- A view of recurring software, service, supply, and support dependencies.
Use the package to choose the next evidence-gathering step. If both routes still depend on an untested sensing assumption, resolving that assumption may be more useful than debating detailed production pricing.
FAQ
Can a first release use a platform and a later release use a custom board?
Yes, if the migration is planned. Preserve interface definitions, test inputs, user behavior requirements, and data formats so the later board can be evaluated against the same experience. Identify which platform licenses or services will not transfer before committing to the first release.
Does a custom board prevent another brand from building a similar product?
No automatic protection follows from having a custom board. Differentiation may depend on design rights, software, data, service quality, and commercial agreements. Define ownership and exclusivity separately from the engineering route, with appropriate professional review of those agreements.
What if neither route meets the target business model?
Revisit the first-release scope and the assumptions behind cost and demand. Identify which requirement drives the mismatch and whether users would accept a different interaction or form. Request another technical review after changing the requirement instead of asking for the same design at an unsupported price.
Should the model team or hardware team make the final choice?
The product owner should coordinate the decision using evidence from both teams and sourcing, operations, and support. A model team can evaluate execution, while hardware engineers evaluate physical implementation. Neither perspective alone establishes that the complete product meets its commercial requirements.
How much detail is needed for an initial route comparison?
Provide the primary user task, essential constraints, available software or hardware assets, intended markets, and the questions still open. Detailed production drawings are not required for that first conversation. State which requirements are firm so the review can identify meaningful alternatives.
Compare the paths against your actual requirements
For custom AI devices, reuse is valuable when it preserves the capabilities the product needs. New design work is justified when it addresses a necessary difference. Ask Yosiya to compare the project paths using your essential requirements, existing assets, and the specific evidence needed to make the next decision.
