Most MCU-selection mistakes aren't visible until months into a project — a part that looked fine on a datasheet turns out to draw too much current in deep sleep, or lacks a peripheral the product actually needs, and by then the PCB is already routed around it. The fix is to weigh the decision on a small set of criteria that actually determine outcomes, rather than defaulting to whatever chip is most familiar.

Start with the power budget, not the clock speed

For a mains-powered device, raw performance and peripheral count dominate the decision. For a battery-powered one, the number that matters most is sleep current — often specified in microamps or even nanoamps in modern low-power MCU families. A part that looks nearly identical to a competitor on paper can differ by an order of magnitude in deep-sleep draw, and that difference compounds over a multi-year battery life target.

The practical exercise is to model the device's actual duty cycle: how much time it spends asleep, awake sampling, and transmitting, and at what current draw in each state. A part with excellent active-mode efficiency but mediocre sleep current will lose to a part with the reverse profile, if the device spends 99% of its life asleep — which most battery IoT devices do.

Match peripherals to the sensor and radio, not the other way around

It's tempting to pick a well-known MCU family first and then adapt the design around it. That usually backfires. Instead, start from what the product needs to talk to — I2C/SPI sensors, an ADC with the right resolution for an analog sensor, a UART for a cellular module, capacitive-touch channels, whatever the bill of materials requires — and shortlist MCUs that natively support that peripheral set without bit-banging or external glue logic. Every peripheral handled in software instead of hardware costs CPU cycles, which costs power, which costs battery life.

Common peripheral gaps that surface late

Toolchain and ecosystem maturity is a real cost, not a footnote

Two MCUs with near-identical datasheets can lead to very different development timelines depending on the quality of the vendor SDK, the availability of a mature RTOS port, community support, and how much of the peripheral driver layer is already written and tested versus needing to be built from scratch. A part that's 10% cheaper in volume but has a thin, buggy SDK often costs far more than the unit-price difference in engineering time — and that's before accounting for how it affects certification prep and OTA tooling down the line.

It's also worth checking second-source availability. A single-source MCU during a component shortage can stall production for months; parts with pin-compatible alternatives across vendors reduce that risk substantially.

Certification and RF considerations, if wireless is involved

For MCUs with an integrated radio (BLE, Wi-Fi, or a sub-GHz protocol), pre-certified modules can meaningfully shorten the path to FCC/CE approval versus a discrete MCU-plus-radio design that requires full RF certification from scratch. That tradeoff — a pre-certified module's higher unit cost against a custom RF design's lower cost but longer certification timeline — is worth resolving early, since it affects the PCB layout, the antenna design, and the project schedule simultaneously.

How we approach this

On client engagements, this is typically the first hardware decision we help scope, because it constrains almost everything downstream — firmware architecture, sensor selection, PCB layout, and certification path. We model the actual duty cycle against candidate parts' datasheets before committing, rather than defaulting to a familiar vendor, and we weigh toolchain maturity as seriously as the electrical specs. See our embedded hardware work for how this fits into a full hardware engagement.