A hardware feasibility study is a short, structured piece of engineering work that answers one question before money is committed: can this product be built, at this cost, in this timeframe, with this risk, and which of the available ways of building it is the right one? It produces ranked architecture options with cost, effort, timeline and risk attached, not a yes or a no.
Most guides to feasibility studies are written for software. They talk about tech stacks and cloud strategy. Hardware is different in a way that matters: the decisions made in the first few weeks get cast into copper, and the cost of changing them rises by roughly an order of magnitude at each stage after. A software team can refactor. A hardware team respins the board.
This guide covers how to run a feasibility study that actually reduces that risk, what it needs as input, what it should hand back, and where the ones that fail usually go wrong.
What a hardware feasibility study answers, and what it does not
A hardware feasibility study answers whether a product concept can be realised with available components at a target cost and timeline, and which architecture gets there with the least risk. It does not answer whether the product should exist. That is the business case, and it comes first. Feasibility takes the business case as given and tests whether engineering can deliver it.
The distinction matters because the two get blurred constantly. A study that spends half its pages on market sizing has stopped being an engineering document. Equally, a study that ignores the target price entirely is not testing feasibility; it is designing in a vacuum. The business case sets the constraints. The feasibility study works inside them.
What it should leave behind is a decision the team can defend: this architecture, at this estimated unit cost, with these known risks, ready to move to proof of concept. Or, just as valuably: none of the options meet the target, and here is what would have to change.
The inputs a study cannot do without
A feasibility study is only as good as its inputs. The minimum set is a target unit cost at a stated volume, a target timeline to production, a list of functional requirements with the ones that are non-negotiable marked, the operating environment, and the expected service life of the device in the field.
Each of these shapes the option space. Cost at volume rules out parts that are fine at a hundred units and ruinous at a hundred thousand. Timeline rules out anything with a lead time longer than the schedule. The non-negotiable requirements are the ones every option must satisfy, and marking them separately from the nice-to-haves is where most of the clarity comes from. Environment decides temperature grades, ingress protection, and whether the radio will work where the device lives. Service life decides whether a part with three years left in production is acceptable.
The most common failure at this stage is a requirements list where everything is marked essential. That is not a requirements list; it is a wish list. A study cannot rank options against a wish list, because nothing can be traded off. Half a day spent forcing the list into must-have and would-like usually saves more time than any other single activity in the study.
Step 1: Map the option space before choosing anything
The first working step is to enumerate the plausible ways of building the product, not to pick one. For an embedded device this typically means three to six candidate architectures spanning different processor classes, connectivity approaches, power strategies, and build-versus-buy decisions on major subsystems. The study’s value comes from comparing them, so the comparison has to exist.
This is where most studies go wrong before they have started. An engineer with experience of a particular MCU family drafts an architecture around it in the first afternoon, and everything after is justification. The part may well be right. But a study that only ever considered one option has not tested feasibility; it has confirmed a preference.
Useful axes for spanning the space:
- Processing: microcontroller, application processor, or both. Bare metal, RTOS, or Linux. Each carries different power, cost, and toolchain implications.
- Connectivity: which radio, or which wired interface, and whether it is a module or a chip-down design. The trade-offs here are covered in depth in the comparison of module standards against chip-down designs.
- Power: mains, primary cell, rechargeable, or harvested. This decides more of the architecture than any other single choice.
- Intelligence: none, rules, on-device inference, or cloud. The edge AI decision framework sets out how to place a product on that spectrum.
- Build vs buy: which subsystems to design and which to source as modules. Modules cost more per unit and less in engineering time; the crossover depends on volume.
Three to six options is the useful range. Fewer than three and the comparison is thin. More than six and the study runs out of time before it can evaluate any of them properly.
Step 2: Find the constraint that binds
For each option, the study has to identify the constraint that actually limits it, which is rarely the headline specification. A part is usually chosen on one number, clock speed or memory or price, and the constraint that later kills the design is almost always somewhere else. Finding it during feasibility costs a datasheet review. Finding it at DVT costs a respin.
Four constraints that bind far more often than the headline figures suggest:
Available memory, not total memory. A microcontroller with 256 KB of SRAM does not have 256 KB for the application. The RTOS, the network stack, the TLS context and the buffers all take their share first. On an edge AI part the inference runtime, the quantised weights and the activation buffers come out of the same pool. The number that matters is what is left, and it is rarely on the front page of the datasheet.
Flash headroom, not flash size. Firmware grows over a product’s life. Anything doing over-the-air updates with A/B images needs room for two of them plus margin. A common rule is at least 30 to 50 percent headroom on day one, and products that treat OTA as an afterthought usually discover this constraint after shipping, when it costs a hardware revision to fix.
Lifecycle stage, not availability today. A part that is in stock and in production this quarter may be in its last years. Mainstream microcontrollers and specialty analog parts typically stay in production for five to eight years. Industrial and medical devices get specified for ten to fifteen. A device that outlives its silicon has a redesign built into it from day one, and the study should say so. Component-intelligence data shows the scale of the problem: more than 620,000 parts went end-of-life in 2025, over half of them without a formal product change notice.
Toolchain and support, not benchmark performance. A part with a strong core and a weak SDK, thin community and one vendor’s proprietary IDE will cost more in engineering time than a slower part with mature tooling. This is invisible in a spec comparison and obvious in month three of development.
The method here is deliberately mechanical. For each option, list every requirement, find the specification that is closest to its limit, and check whether the margin survives the real conditions the device will see. The constraint that binds is the one with the least margin. Often it is not the one anyone expected.
Step 3: Cost at target volume, honestly
A feasibility study has to produce a unit cost estimate at the target volume, built from a real bill of materials with real quoted pricing at that quantity, plus the non-recurring engineering cost to reach production. Estimating from single-unit pricing or from a similar product’s known cost is not costing; it is guessing with a spreadsheet.
Three things make hardware cost estimates go wrong:
Quoting at the wrong volume. Part pricing has steep breaks. A sensor that costs €4.20 in singles may be €1.15 at 10,000. The study has to price every significant line at the target quantity, not at whatever quantity the distributor site defaults to.
Ignoring the things that are not on the BOM. Assembly, test, programming, packaging, certification, tooling for enclosures, and the cost of the first production run’s yield losses. On a low-cost device these can exceed the component cost. A study that stops at the parts list understates the number by a factor that varies but is never small.
Treating NRE as a footnote. The non-recurring cost to design, prototype, certify and bring a product to production is the largest single number in most hardware projects, and it differs sharply between options. A module-based design has lower NRE and higher unit cost. A chip-down design has the reverse. Which is cheaper depends entirely on volume, and the study should show the crossover point rather than assert one answer.
The output is not a single number per option. It is unit cost at target volume, NRE to production, and the volume at which the ranking between options changes. Those three together are what a decision-maker actually needs.
Step 4: Build the risk register, and be specific
Every architecture option carries risks, and the study’s job is to name them concretely enough that they can be managed. A risk register that says “component availability” has said nothing. One that says “the LTE modem is single-sourced, has a 40-week lead time, and the vendor’s roadmap shows it entering last-time-buy in 2028” has given the team something to act on.
Categories that reliably produce real entries:
- Supply: single-sourced parts, long lead times, parts near end of life, parts from vendors with a history of allocation.
- Technical: unproven interfaces, timing margins that are tight on paper, thermal budgets that depend on assumptions about the enclosure, RF performance that has not been measured in the intended environment.
- Certification: the route to the required marks, and whether the chosen radio module carries pre-certification that survives the intended integration.
- Schedule: the items on the critical path that depend on things outside the team’s control, typically silicon samples, certification lab slots, and tooling.
- Team: the skills the chosen architecture assumes that the team does not currently have.
Each entry gets a likelihood, an impact, and a mitigation or a decision to accept it. The register is not a list of things that might go wrong. It is a list of things the team has decided how to handle.
What a good study hands back
The deliverable of a hardware feasibility study is a ranked comparison of architecture options, each with an estimated unit cost at target volume, NRE to production, a timeline, and a specific risk register, together with a recommendation and the reasoning behind it. It should be short enough to read in an hour and specific enough that an engineer could start the proof of concept from it the next morning.
A useful test of whether the study is finished: could someone who was not in the room make the decision from the document alone? If the answer depends on context that lives only in the authors’ heads, the study is not done.
What it should not contain: a single option presented as inevitable, cost figures without the volume they were quoted at, risks stated as categories rather than specifics, or a recommendation that ignores the target price because the engineering was more interesting at a higher one.
And one thing it should say explicitly if it is true: none of the options meet the target. That is a legitimate and valuable conclusion. A study that finds this in two weeks has saved the six months it would have taken to discover it at DVT.
When to run one, and how long it takes
A feasibility study belongs before the proof of concept, not after. Once a prototype exists the architecture has been chosen, whether or not anyone chose it deliberately, and the study becomes a justification of the sunk cost. The right moment is when the business case is clear enough to set the constraints and before anyone has committed to a part.
For a typical connected device with a well-defined requirements list, a focused study takes two to four weeks of senior engineering time. Longer than that usually means the requirements were not settled, or the option space was allowed to sprawl. Shorter usually means the costing or the risk register was skipped.
The economics are not subtle. Two weeks of feasibility work costs a small fraction of one hardware revision. The stages that follow, from EVT through DVT and PVT to production, each multiply the cost of a wrong early decision. A study is cheap precisely because it happens before anything has been built.
Frequently asked questions
What is the difference between a feasibility study and a proof of concept? A feasibility study is an analytical exercise that compares architecture options on paper, using datasheets, quoted pricing and engineering judgement, before anything is built. A proof of concept builds the chosen option to test the riskiest assumption in practice. The study comes first and decides which concept is worth proving.
How much does a hardware feasibility study cost? For a typical connected device, two to four weeks of senior embedded engineering time. Against the cost of a single board respin, or of discovering at DVT that the target unit cost cannot be met, it is the cheapest engineering work in the project.
Can a feasibility study be done without a target cost? Not usefully. Without a target cost at a stated volume there is nothing to rank options against, and the study degenerates into a survey of what is technically possible. A rough target is far better than none. It can be revised once the study shows what is achievable.
What is model-based solution space exploration? It is the practice of encoding a product’s requirements, constraints and budget into a structured model, then using that model to explore and rank architecture options rather than comparing two or three candidates by hand. The advantage is that changing one constraint, such as the target volume or the service life, updates the ranking of every option at once, which makes the trade-offs visible rather than argued.
What is the most common mistake in hardware feasibility studies? Choosing the architecture on the first day and spending the rest of the study justifying it. The second most common is a requirements list where everything is marked essential, which makes ranking impossible because nothing can be traded off.
How is hardware feasibility different from software feasibility? The cost of changing a decision. Software architecture can be refactored incrementally. Hardware architecture is committed to a board, and changing it after layout means a respin, a requalification cycle and, in regulated markets, a fresh certification. The stakes at the feasibility stage are correspondingly higher.
Better Devices runs feasibility and architecture studies for hardware product teams, including model-based exploration of the option space, cost modelling at target volume, and risk analysis before any part is committed. If a product is at the point where the business case is clear and the architecture is not, a senior engineer will talk it through.