Hardware gets easier when software founders stop pretending the factory is the only risk

Indie hardware is not suddenly easy; the useful change is that a disciplined software builder can now treat small physical products as a design, margin, and operations problem instead of as an automatic manufacturing horror story.

The trending item I picked is Chip Weinberger’s July 19, 2026 essay, “What I learned selling 2500 MIDI recorders, part 1: Hardware is not so hard.” Weinberger writes about Jamcorder, a small device for digital pianos that records MIDI performances automatically. His central claim is deliberately unfashionable: the hardware side of the product went more smoothly than he expected, while the software remained the hard part.

That is worth reading because it cuts against two lazy stories at once. The first is the old “hardware is hard” warning, which often functions less as wisdom than as a way to keep software people in their lane. The second is the newer maker-culture overcorrection, where a prototype, a storefront, and a supplier relationship are treated as a business. Weinberger’s example supports neither fantasy. It says something narrower and more useful: for a simple, margin-protected product, hardware risk can be made boring if the product is aggressively constrained.

Weinberger’s facts are self-reported, and they should be read that way. He says Jamcorder has sold 2,500 units. He says he hand-assembled the first 500 units in four days. He says the hard part was about 200,000 lines of code across firmware, app, and manufacturing tooling, built over more than three years. He says the printed circuit board has 25 unique components, with made-to-order MIDI connectors and the rest off the shelf. He also lists the design decisions that made the product less ambitious: one screw, one board, generous draft in the injection mold, no slides, no low-battery detection, no ambient-light detection, no power button, and no USB-C.

The lesson is not that every developer should start a hardware company. It is that the cliché is too blunt. “Hardware is hard” hides the variable that matters most: what kind of hardware, with what assembly path, what support burden, what inventory exposure, what software surface, and what gross margin. A keyboard accessory with one board and a small enclosure is not a phone, a watch, a router, or a safety-critical instrument. It does not carry the same certification, repair, radio, battery, thermal, or retail-channel complexity. The product category does not remove risk, but it changes the risk profile enough that the generic warning becomes bad advice.

For software teams, the sharpest part of Weinberger’s post is the inversion. The physical object can be simplified in ways customers may barely notice. The software often cannot. A missing ambient-light sensor may be a non-event. A clumsy app, unreliable capture, opaque sync model, confusing onboarding, or weak recovery path can break the whole promise. Jamcorder’s public site describes the product as a tiny device attached to a digital piano that captures what a user plays, with automatic play detection and a personal archive. The underlying standard matters here: the MIDI Association describes MIDI 1.0 as a hardware and software specification for exchanging musical notes, program changes, and expression-control data between instruments and other devices. That means the buyer is not really buying a board in a box. The buyer is buying trust that a fleeting performance will be there later.

That trust is mostly software. Firmware must capture the right events. The app must make retrieval simple. Storage and export must feel safe. The product must avoid the classic hardware trap where the first unboxing delights and the second week exposes a brittle companion app. In that sense, Weinberger’s “hardware is not so hard” line is less a dismissal of factories than a warning to software founders: do not use manufacturing fear as an excuse to undercount product software. The casing may ship once. The user experience ships every time the device is used.

The strongest counterargument is that survivorship bias is doing real work here. Weinberger is describing a product that appears intentionally narrow, value-dense, and founder-operated. He also says the hardware would have been a different story at 10 times the complexity or 100 times the scale. That caveat matters. Hardware failure is often nonlinear. A design that works at a few hundred units can reveal supplier, yield, packaging, customs, support, cash-flow, counterfeit, or quality-assurance problems later. A product that avoids batteries, radios, screens, and moving parts is not evidence that products with those elements are manageable by analogy.

The counterargument does not weaken the column’s practical value. It defines the boundary. The important question for an indie builder is not “Is hardware hard?” The important question is “Can I make my hardware this boring?” If the answer is no, the team should be honest about that before taking money, announcing ship dates, or building a software roadmap around a physical promise it cannot fulfill.

A useful indie hardware checklist falls out of this story. Start by deleting features that create supply-chain, assembly, calibration, battery, thermal, or support complexity without changing the core job. Weinberger explicitly names several cuts. That is not austerity for its own sake; it is product strategy. Every sensor, connector, enclosure flourish, and power-state behavior has a downstream cost. Hardware rewards taste, but it punishes vanity.

Second, protect margin before launch, not after the first painful batch. Weinberger recommends aiming for at least 70% gross margin. That is his recommendation, not a universal law, but the direction is right. A small hardware company needs room for replacements, shipping surprises, payment fees, returned inventory, revised packaging, support time, and batches that do not go perfectly. Software founders used to near-zero marginal distribution costs can dangerously underprice physical goods because the prototype bill of materials looks comforting. The bill of materials is not the business.

Third, treat manufacturing documentation as product code. Weinberger recommends a step-by-step manufacturing and assembly guide with pictures, samples before every production run, final quality assurance in-house, and local finished inventory. Those are operational controls. They are also a form of interface design between the founder and the factory. If a team would not accept an undocumented deployment path for a web service, it should not accept an undocumented assembly path for a device.

Fourth, plan the anti-counterfeit and support story early. That may sound premature for a small run. It is not. A physical product creates a visible shape, a supply trail, and customer expectations that a pure app does not. A good clone can damage the original seller’s reputation; a bad clone can create support load and trust confusion. Even without counterfeits, support for a device lives at the boundary between hardware, software, cables, instruments, operating systems, and user habits. That boundary needs logging, diagnostics, clear warranty language, and plain-language failure modes.

The builder takeaway is simple: ship hardware only if you can make the hardware boring enough that the software and operations get the attention they deserve. If the product’s magic depends on a complicated enclosure, a fragile supply chain, or a margin that assumes nothing goes wrong, stop. If the product can be reduced to a small number of parts, simple assembly, clear documentation, durable margin, and a software experience that owns the user’s real job, then the old warning should not scare you away.

Weinberger’s post is strongest when read as a constraint manifesto, not a victory lap. Hardware did not become easy. He made a version of hardware that could be easier. That distinction is the whole lesson.

Sources

• Chip Weinberger: “What I learned selling 2500 MIDI recorders, part 1: Hardware is not so hard”
• Jamcorder product site
• MIDI Association: MIDI 1.0

---

Shadowfetch is an independent news publication. Explore Shadowfetch Linux — our own Linux build — and the Shadowfetch apps on the App Store.