Edge deployments usually fall into three groups: mobile devices, embedded Linux gateways, and microcontrollers. Each tier changes the feasible model size, runtime stack, and observability depth you can realistically support.

Teams that skip tier definition often design for desktop-class assumptions and then fail during hardware bring-up. A clear tier decision early prevents expensive rework across model, firmware, and product requirements.

Write a deployment decision memo for one real feature and force each requirement into one of the edge tiers. This prevents architecture arguments from drifting into preference debates.

Always-on keyword spotting, safety triggers, and control loops usually need low and predictable latency without network dependency. In these cases, local inference is a reliability requirement, not just a performance optimization.

Tiny deployments are expected to keep working during intermittent connectivity, power fluctuations, or bandwidth limits. Designing for offline-first behavior protects user trust and simplifies failure handling in the field.

Teams often over-scope tiny deployments by adding open-ended language tasks that belong to richer edge stacks. Keep TinyML workloads bounded and action-oriented to preserve reliability.

Typical TinyML workloads include keyword spotting, visual wake word detection, vibration anomaly alerts, and simple classification on sensor streams. These tasks reward compact models with stable behavior under noisy inputs.

Open-ended generation and multi-step reasoning usually exceed strict MCU budgets and belong on stronger edge tiers. Tiny systems work best when outputs are bounded, testable, and tightly mapped to product actions.

Validate decisions with real field constraints such as network loss, device sleep behavior, and wake-time budgets. Synthetic desktop checks rarely predict behavior on constrained targets.

Use five inputs: maximum latency, privacy sensitivity, power budget, network reliability, and maintenance model. This framework keeps architecture decisions tied to product requirements instead of tooling preferences.

If constraints relax over time, you can move from TinyML toward richer edge runtimes or hybrid cloud designs. A documented escalation path keeps model interfaces stable while underlying infrastructure evolves.

Require cross-functional sign-off from product, firmware, and ML owners before committing to the target tier. Early alignment reduces downstream rework and roadmap churn.

Define target hardware, response-time budget, power profile, expected input range, and failure behavior before model training starts. These constraints shape data collection and directly influence model architecture choices.

Success should include quality metrics plus operational metrics such as RAM peak, startup time, and field stability. TinyML programs fail when teams optimize for accuracy only and ignore operational acceptance gates.

Capture tier assumptions, model boundaries, and escalation paths in versioned docs so future updates do not break the original deployment logic. Review it at each release checkpoint so assumptions remain current.

Warning signs include changing hardware targets mid-cycle, undefined offline behavior, and missing power acceptance criteria. These issues should trigger a scope review before additional model tuning work is approved.

Run a design checkpoint before model lock that revalidates tier choice against product requirements and deployment constraints. This checkpoint is often the highest-leverage quality gate in edge projects.

Confirm tier selection, latency budget, power budget, privacy requirements, and offline fallback behavior in writing. Each item should have an accountable owner and measurable acceptance condition.

Revisit this checklist at architecture freeze, first-device bring-up, and pre-release. Repeated review catches assumption drift and keeps engineering effort focused on the right deployment class.