The fastest way to waste an embedded AI budget is to skip the feasibility question. Not every sensing problem fits on a microcontroller, and the honest audit — data, model size, power, sensors — takes days, not the months you'd spend discovering a mismatch in the field.
Here's the checklist we run before any TinyML engagement, so you can run it on your own product first.
Start with the decision, not the model
The first question is never 'which model?' — it's 'what does the device decide?' Write the decision in one sentence: 'flag the bearing when vibration drifts', 'unlock when the enrolled voice is heard', 'sleep until a person is present'. If you can't state it crisply, the project isn't ready for a model.
Then ask whether a threshold would do it instead. A surprising share of 'AI' features on devices are honestly implemented as a bandpass filter plus a comparator. If a simple heuristic captures 95% of the value, ship that — and keep AI budget for the cases where heuristics genuinely fail.
Data: quantity, quality, and labels
Feasibility lives or dies on data. Do you have representative recordings from the actual sensor, in the actual mounting, across the real range of environments and edge cases? Or synthetic and dev-kit data? Models trained on bench data routinely fail on field units — the signature you need lives in production conditions.
For supervised tasks you need labels, and labeling is usually the underestimated cost. Rare-event problems (machine failure, falls) may have hundreds of examples, not thousands — which steers you toward anomaly detection, transfer learning, or data augmentation strategies instead of naive supervised training.
- Field-collected data beats dev-kit data, every time
- Rare events → anomaly detection or augmentation strategies
- Label quality matters more than label quantity
- Plan for drift: environments and sensors change over product life
Fit the budget: memory, power, latency
Three hard numbers bound the design. Memory: does a compressed model plus runtime fit your flash/RAM? Power: what does per-inference energy cost at your duty cycle versus the battery? Latency: does the inference finish inside the decision window — per audio frame, per sample batch, per event?
Any one of the three can be the binding constraint. An always-on audio product is power-bound; a vision classifier is usually memory-bound; a closed-loop vibration controller is latency-bound. Knowing which wall you're nearest to shapes the architecture before training starts.
The honest 'not yet' cases
TinyML is a poor fit when the task needs large context — natural-language understanding, multi-object video analytics, generative anything. It's also premature when no field data exists yet; the right first deliverable is a logging build that collects a dataset, not a model.
The audit ends with a recommendation in one of three buckets: feasible now, feasible with a larger processor or hybrid architecture, or not yet — collect data first. A good audit tells you which bucket you're in before you've spent the engineering budget to find out.
Frequently Asked Questions
How much data do I need for an embedded AI model?
It depends on task complexity and class balance, but rough anchors: hundreds of minutes of representative audio for keyword spotting, a few hundred labeled windows per class for IMU activity recognition, and weeks of normal-operation data for anomaly detection. Rare-event tasks often pair limited real data with augmentation or anomaly-modeling rather than chasing balanced supervised sets.
What if my sensor data is noisy or inconsistent?
Deal with it at the pipeline level before the model level — filtering, normalization, and feature engineering fix more accuracy problems than bigger models do. Also verify the noise isn't mounting or placement related: a poorly coupled accelerometer corrupts the signal no model can recover.
Should I prototype on a dev kit or go straight to custom hardware?
Dev kit, almost always. Prove the model works on an off-the-shelf board with your real sensor attached before committing to custom silicon or board spins. Hardware locks in early; models iterate late. The dev-kit phase exists to learn which MCU class and memory budget you actually need.
What does a feasibility audit cost in time?
A serious audit is days to a few weeks: reviewing data samples, target hardware, power budgets, and decision requirements, plus small prototype benchmarks when the case is ambiguous. Compare that to a full development cycle — the audit is the cheapest insurance in the entire project.
Building something that should run AI on-device?
Edgehound designs, compresses, and deploys TinyML models on microcontrollers — from feasibility audit to field-ready firmware.