"How long will the battery last?" is usually the first question a client asks about an IoT sensor node, and it's frequently answered with a rough guess rather than an actual power budget. That guess almost always turns out wrong once real firmware and real radio behavior enter the picture.
A proper power budget starts by breaking the device's operating cycle into discrete states — deep sleep, sensor sampling, radio transmit, radio receive/listen window — and measuring or estimating current draw and duration for each. Deep sleep current on a well-designed board should be in the low microamps; if it's not, that single number often dominates the entire battery life calculation regardless of how efficient your transmit behavior is.
Radio transmit is usually the largest single current draw, but it's typically also the shortest duration — which means transmit duty cycle, not peak current, is what actually matters for total energy consumption. A device transmitting for 50ms every hour has a vastly different energy profile than one maintaining a persistent connection, even with identical peak transmit current.
We build this as an actual spreadsheet model before component selection: state, current draw, duration, frequency, multiplied out to average current, then divided into the battery's usable capacity (not nameplate capacity — accounting for self-discharge and the voltage cutoff your regulator actually requires). This model gets validated against bench current measurements once firmware is running, and it's the same model that determines whether a coin cell is viable or whether the product needs a larger battery or energy harvesting.
Getting this sequence right — model first, then measure, then adjust firmware behavior against the model — is the difference between a battery life spec that holds up in the field and one that quietly becomes a support problem six months after launch.