When would you argue against shipping a product on a consumer Raspberry Pi board, and what would you move to instead?

## Start with what the Pi is genuinely good at A principal-level answer does not open by listing weaknesses. The Pi wins on *engineering economics*: your device runs the same Linux userland your developers already know, with the same package ecosystem, the same debugging tools and the same language runtimes. That collapses the cost of getting from prototype to something demonstrable, and it means hiring for it is easy. For a low-volume product where the differentiation is in software, that advantage often outweighs everything below. The question is where it stops being true. ## Environment Consumer Pi boards are specified for an ambient range appropriate to a room, not to a roadside cabinet or an unheated warehouse — the official operating range for the mainstream boards tops out around 50 °C ambient, and the board arrives with no conformal coating, no vibration-rated connectors and a socketed card. If your enclosure sees direct sun, condensation, dust or vibration, you are operating out of spec and your field failure rate will tell you so. Industrial SBCs exist precisely for the wide-temperature, coated, ruggedised case, and they cost more for exactly those reasons. ## Determinism Linux is a general-purpose scheduler. Even with the real-time preemption work now in mainline, a Linux board is not the right home for a control loop that must respond within microseconds, deterministically, every time. This is the argument people get wrong in both directions: they either insist Linux can do it because their test looked fine, or they abandon Linux entirely. The mature answer is usually a split — a microcontroller owns the hard real-time loop and the Pi owns networking, storage, updates and the interface, talking to it over a serial link or SPI. You get determinism where it is required and a rich OS where it pays. ## Data integrity and unattended lifetime There is no ECC memory on these boards. For a device that reboots daily and displays a dashboard, nobody cares. For one that runs unattended for years accumulating measurements, an undetected bit flip is a real and unhandled risk, and the mitigation has to move into your application — checksums on stored data, and a design that tolerates a restart. Storage is the same story: the SD card is a single point of failure with consumer endurance, which is why moving to soldered eMMC or an NVMe-backed design is the first change most products make. ## Mechanics, connectors, and the module answer A consumer board's value — a fixed layout with a full-size HDMI, USB stack and Ethernet jack — becomes a liability inside a custom enclosure. This is the specific problem the Compute Module family solves: the same SoC and software, delivered as a module with eMMC soldered on, that you place on a carrier board carrying exactly the connectors your product needs, positioned where your enclosure wants them. Practically every serious product built around this platform ends up there. You keep the ecosystem and the developer familiarity; you shed the SD socket, the connector layout you did not choose, and a class of mechanical failure. ## Lifecycle and supply For a product you will sell for years, availability of the exact board matters more than its price. Raspberry Pi publishes long production-availability commitments for its models, which is a genuine advantage over generic boards that vanish without notice — but a component-availability shock still hits a single-source design hard. A principal weighs that: how much of the design is portable to another board if this one becomes unobtainable, and is there a second source for the parts that are not. ## Operability in the field The last axis is the one engineers forget until the first deployment. A device you cannot physically reach needs answers for: how firmware and OS updates are applied and rolled back when one fails halfway; whether the board recovers on its own after a hang, which is what the on-board hardware watchdog is for; how the clock is correct at boot on models with no battery-backed RTC before network time arrives; and how you get diagnostics off a device with no screen. These requirements do not disqualify the Pi — but if the answer to any of them is "someone will drive out there", that is the number to put next to the unit cost when you compare it with a more capable board. ## Framing the recommendation The answer an interviewer is listening for is a *decision procedure*, not a verdict. State the requirement axes — environment, timing, integrity, mechanics, lifecycle, serviceability — establish which ones the product actually has, and match the platform to those. Consumer Pi for prototypes, internal tools and low-volume products in benign environments; Compute Module for a real product that wants the ecosystem; industrial SBC when the environment is hostile; microcontroller, standalone or alongside, when timing or power budget is the binding constraint.