How We Scope an Embedded PoC: A Framework That Actually Works

Why a PoC First

Embedded and edge systems have a property that pure software projects do not: the unknowns are physical. A web application can be iterated quickly in production. A device deployed in a factory, a vehicle, or a medical environment cannot. By the time a hardware problem surfaces after full-scale development, the cost to fix it — in engineering time, in tooling, sometimes in PCB respins — is an order of magnitude higher than discovering it in a four-week proof-of-concept.

A PoC is not a prototype. A prototype is a partial implementation of the final product. A PoC answers a specific question: is this technically feasible on this hardware in this environment? It is intentionally narrow. It proves the hard thing first.

The Three Questions That Define a Good PoC

Before writing a single line of scope, we ask the client three questions. The answers determine what the PoC must demonstrate — and, equally important, what it does not need to.

What is the single biggest technical risk in this project?
Not the biggest feature — the biggest risk. The thing that, if it does not work, makes the rest of the project irrelevant. A PoC is designed to attack that risk first. Common answers: latency of edge inference on target hardware, sensor accuracy in the actual operating environment, communication reliability in a specific RF environment.
What does success look like, in measurable terms?
"It works" is not a success criterion. "Inference latency under 40 ms at 1080p on Jetson Nano in the target temperature range" is. We insist on quantified success criteria before starting. If the client cannot define them, defining them together is the first deliverable.
What hardware will be available, and when?
PoCs running on dev kits that do not match the final hardware produce misleading results. If the production board is not available, we document the delta and what it means for the results. Hardware availability often gates the PoC timeline more than engineering effort does.

What Goes In Scope

A well-scoped PoC contains the minimum necessary to answer the technical question and produce a transferable artifact. Typically this includes:

Target hardware brought up to the point required for the test
One complete path through the critical subsystem — not all subsystems
Measurement tooling to capture the success criteria quantitatively
A working build that a client engineer can run independently
A written summary: what was tested, what the results were, what was not tested

What is explicitly out of scope: production-quality error handling, UI, cloud integration, security hardening, documentation beyond the summary, and anything not needed to answer the technical question. These are not excluded because they are unimportant — they are excluded because building them before you know the core approach works is waste.

The artifact rule: A PoC must produce a working artifact — compiled firmware, a runnable script, a captured log file showing the measurement — not a slide deck. If the only output is a presentation, it was not a PoC; it was a study. Studies are sometimes appropriate, but they are priced and titled differently.

Typical Timeline

Most embedded PoCs fit within four to six weeks. The structure we follow:

Week 1: Environment setup, hardware bring-up, baseline measurements. Identify any blockers early — hardware that arrives damaged, toolchain issues, access requirements.
Weeks 2–3: Core implementation focused on the risk area. Frequent informal check-ins rather than formal milestone reviews — the goal is to surface surprises early, not at the four-week mark.
Week 4: Measurement against success criteria, edge case testing, documentation. If the PoC is succeeding, scope discussions for the next phase begin here in parallel.
Final delivery: Working build, measurement data, written summary. Go/no-go decision against the defined criteria.

Common Failure Modes

In roughly descending order of frequency:

Success criteria defined after results are in. This is the most common and most corrosive failure mode. If success is defined retrospectively, any result can be called a success. Define criteria in writing before work starts, and do not change them during the PoC without documenting the change and the reason.
Scope creep from stakeholders not in the original conversation. A product manager joins the project midway and adds requirements. This is normal in product development; it is lethal in a PoC. New requirements go to a parking lot for the full project, not into the PoC.
Hardware unavailability treated as a schedule risk rather than a scope risk. If the production hardware does not arrive, the PoC should either pause (if the dev kit results would be meaningless) or explicitly document the delta (if dev kit results are informative with caveats). Running a PoC on the wrong hardware and treating the results as definitive is worse than not running one at all.
PoC mistaken for a minimum viable product. A PoC that meets its criteria should not go to production. It was built to prove a point, not to ship. The full project takes the learnings from the PoC and builds the production system correctly, with appropriate robustness, security, and documentation.

The Go/No-Go Decision

The PoC ends with a clear binary outcome against the pre-defined success criteria. Three possible states:

Go: Criteria met. Proceed to full project with a well-understood baseline.
Conditional go: Criteria partially met with a defined path to resolve the gap. Agree on what changes before full project authorisation.
No-go: Criteria not met. This is a good outcome. A no-go at PoC stage costs four weeks. A no-go discovered after a six-month full project costs far more — and may not be recoverable.

Our standing offer: Every AGNIDYNE engagement begins with a fixed-scope, fixed-price PoC. You get a working artifact and a clear decision point — not a commitment to a full project before the hard questions have been answered. Get in touch if you want to discuss scoping one.