Flipper One stalls: maker asks community to help build the sequel

What happened

Flipper Devices, the team behind the Flipper Zero — the orange dolphin-shaped pentesting toy that became a TikTok phenomenon and a regulatory headache in several countries — published an open letter on their blog titled "Flipper One – we need your help." The post is a candid admission that the sequel device, announced years ago alongside the original Zero's Kickstarter, is harder to build than they anticipated, and that the existing team can't finish it alone.

Unlike the Zero, which runs bare-metal firmware on an STM32 microcontroller, the Flipper One is targeting a Linux-capable application processor with a separate MCU for real-time radio work — a hybrid architecture that effectively means shipping two devices in one enclosure. The blog post enumerates specific engineering disciplines the team is short on: Linux board support package (BSP) developers, RF engineers fluent in sub-GHz and 2.4GHz stacks, hardware security specialists, and firmware architects who have shipped dual-core heterogeneous systems before. It's not a generic recruiting post — it reads like a triage list.

The Hacker News thread (487 points at time of writing) is overwhelmingly sympathetic, with several commenters noting that the honesty is refreshing compared to the usual Kickstarter pattern of silent delays followed by a sudden "we're shipping!" announcement that turns out to be aspirational. A handful of comments raise the obvious concern: if the team is asking for help this publicly, are pre-orders or deposits at risk? Flipper Devices has not opened pre-orders for the One, which mutes that critique.

Why it matters

The Flipper Zero is one of the few genuinely successful indie hardware stories of the last decade. It sold out repeatedly, spawned an active third-party app ecosystem, and survived a Canadian government attempt to ban it as a "car theft tool" (which would have been roughly as effective as banning screwdrivers). The Zero worked because it picked a hard but bounded scope: bare-metal firmware, one MCU, a fixed feature set that could be reasoned about end-to-end by a small team. The One throws that constraint away.

Going from a microcontroller to a Linux SoC is not a linear difficulty increase — it's a phase change. You inherit the entire Linux kernel surface area, including its driver maintenance burden, its security update treadmill, and its boot complexity. You inherit a bootloader story (U-Boot or otherwise), a root filesystem to maintain, package management decisions, OTA update mechanics that have to survive bricking, and a userspace where memory management is suddenly your problem in a way it wasn't on an STM32. The team is also clearly trying to keep the real-time RF work on a dedicated MCU, which means inter-processor communication, shared memory protocols, and a clock domain handoff — all the fun stuff that makes embedded engineers expensive.

The community reaction reveals an interesting split. One camp argues Flipper should just ship a beefier MCU-based device — a "Flipper Zero Pro" — and skip Linux entirely. The other camp points out that the most-requested features from the Zero community (Wi-Fi pentesting beyond the dev board, full BLE stack work, packet capture, USB host) realistically need a Linux-class system. Both camps are right, which is the worst possible situation for a hardware roadmap: there is no consensus product to build, and the team has committed publicly to the harder option.

There's also a quieter signal in the post about the security model. The Zero is intentionally not a hardened device — it's a hacker tool, and that's part of its appeal. The One, by virtue of running Linux with networking, becomes a much juicier target. The team's explicit ask for hardware security expertise suggests they understand they're now in the business of secure boot chains, signed update images, and a threat model that includes the device being remotely exploited rather than just stolen. That's a different company than the one that shipped the Zero.

What this means for your stack

If you're an embedded engineer who has shipped a production Linux device — actually shipped, not built a Raspberry Pi prototype — this is a credible opportunity. Flipper has a real distribution channel, a rabid community of about 500,000 Zero owners, and apparently enough runway to be picky about who they hire rather than panic-shipping a half-baked board. The roles are remote-friendly based on prior Flipper hiring patterns, and the work will land in actual hands rather than a pilot that gets cancelled.

If you're building your own hardware product, the post is worth reading as a case study in scope discipline. The Zero succeeded by being aggressively constrained. The One is what happens when a successful constrained product tries to expand into adjacent capability — and it's a cautionary tale even before it ships. Every "we should also support X" decision compounds: Linux pulls in Wi-Fi, Wi-Fi pulls in a TCP/IP stack you didn't write, the stack pulls in CVE management, CVE management pulls in an update infrastructure, and now you're running a fleet management product instead of selling a gadget.

For practitioners using the Zero in red-team or research contexts, the practical implication is that the One is not arriving on any near-term timeline you can plan around. If your workflow depends on "the next Flipper will do Wi-Fi properly," build the Wi-Fi rig yourself with an ESP32 or a Pi Zero W and stop waiting. The community response to the blog post suggests realistic shipping is 2027 at the earliest, and that's assuming the hiring works out.

Looking ahead

The most interesting thing about this post isn't the technical content — it's the precedent. A hardware company with a successful first product publicly admitting it needs help on the second is rare, and the alternative (silent delay followed by a quiet product cancellation) is far more common. If Flipper actually closes these roles and ships the One, they will have demonstrated a model for indie hardware that doesn't require pretending everything is fine. If they don't, the Zero will stand as a reminder that the second product is always harder, and that going from MCU to Linux is one of the most expensive architectural decisions a small team can make.