When a Retired Engineer's Blueprint Became Our ultralyx Community's First Product

It started with a fax. Yes, a fax—in 2022. A retired mechanical engineer, let's call him Frank, sent a three-page blueprint to our community forum. He'd been building robots since the 1970s, and his handwriting mixed cursive with block capitals. The design was a chassis for a small educational arm. We argued about it for weeks. Some called it outdated. Others saw genius. Six months later, that fax became our first community-sourced product. Here's how it happened, and the messy reality of turning one person's hobby sketch into something you can buy.

Where a Fax from a Retired Engineer Fits in Real Work

The typical lifecycle of community blueprints

Most blueprints never leave a manila folder. I have seen binders full of brilliant mechanisms—incrementally perfected over decades—that die in garages because nobody asked the right question: Who else needs this? That was nearly the fate of Frank's fax. He sent it on a Tuesday, three pages of hand-drawn isometric views with coffee-ring annotations. No CAD file. No BOM. Just graphite and the kind of precision that comes from forty years of catching other people's mistakes. The ultralyx community had been chasing a different problem entirely—actuator chatter on lightweight frames—but Frank's linkage geometry solved it by accident. Worth flagging: the fax sat unread for six days. Someone had to notice the paper was thermal fax paper, already fading. That urgency—the physical degrading of the artifact—forced a decision most hobby groups avoid: treat it like product or let it rot.

How Frank's design solved a problem we didn't know we had

Our builds had a silent failure mode. Joint backlash accumulated across three axes until a robot that worked on the bench wobbled under load. We threw more stiffening at it. Aluminum brackets. Thicker fasteners. The catch is—Frank saw the linkage as a compliance adjuster, not a stiffness adder. His sketch showed a nested parallelogram with a single eccentric pivot. The underlying insight: absorb the backlash, not fight it. Most teams skip this kind of lateral thinking because they're looking for the obvious fix. Frank wasn't solving our documented problem; he was solving the real one. That sounds fine until you try to turn a pencil sketch into something reproducible. The geometry relies on three loose tolerances that only work when the frame flexes a specific way. Change the material thickness by even 0.5 mm and the mechanism binds. Change the fastener torque and you lose the self-centering behavior. Suddenly a generous blueprint becomes a trap—one that only Frank's intuition could navigate. Not a startup story. A community story where one retired engineer's muscle memory became our product's secret sauce.

“I didn't design it for manufacturing. I designed it for my lathe, my scrap bin, and a Tuesday afternoon.”

— Frank, 72, retired mechanical engineer, still irked that we asked for a PDF

Why this isn't a startup story—it's a community story

The tricky bit is that startups optimize for speed. We optimized for does Frank approve? That's a slower loop. When a VC-backed hardware firm receives a blueprint, they run DFM analysis, kill features, and push a minimum viable product out the door inside twelve weeks. We spent twelve weeks arguing about whether the fastener head should be hex or Torx—because Frank's original used whatever was in his drawer and hex felt like betraying the original intent. That tension—between preserving authenticity and manufacturing sanity—almost broke the project three times. What usually breaks first is not the technical challenge; it's the social contract. Someone on the community board said, "We could just ignore Frank's note about the spring preload and tune it in software." Wrong order. That move would have converted a community artifact into corporate R&D wearing a friendly mask. The real cost of keeping a community design alive is saying no to shortcuts that feel like progress. We lost a month on sourcing a specific nylon washer that Frank had cut from a milk jug. Worth it. That washer is now a joke in the build notes and a signature detail that members recognize instantly. You can't buy that kind of identity. You have to earn it by letting the engineer's original constraints dictate your schedule—not the other way around. That's where a fax from a retired engineer fits: not as a rough draft for a product, but as the constitution for how you will treat the next ten designs that come through the community.

What Most People Get Wrong About Scaling a Hobby Design

The myth that a working prototype equals a production-ready design

We learned this the hard way—our first chassis prototype ran beautifully on the retired engineer's workbench. It drove laps around his garage track for three straight weekends. We all celebrated. Then we ordered twenty sets of laser-cut parts from the same DXFs he emailed us. What came back was a pile of aluminum rectangles that didn't fit together. Wrong order. The trick is: a prototype is a proof of concept, not a manufacturing definition. On his bench, he could file a hole 0.2mm wider in thirty seconds. In our community batch, that mismatch multiplied across forty joints. That sounds fine until the motor mounts no longer align with the gearbox. I have seen three separate hobby projects die right there—trying to scale a one-off fit into a production jig. The gap between "it works" and "it works consistently" is the place most teams stop returning emails.

Material and tolerance differences between one-off builds and batches

That retired engineer used 6061-T6 aluminum from a local supplier who stocks offcuts. Our first bulk order came from a different mill—slightly harder alloy, different grain direction, and a 0.1mm variation across the sheet. The catch is: the prototype's center hole for the axle was cut with a waterjet his neighbor runs part-time. The production run used a laser cutter with a different kerf width. Suddenly a 10mm bore became 9.7mm on two-thirds of the plates. We fixed this by switching vendors, but not before wasting eight complete kits. Costs vary per batch, per supplier, per season. What most people get wrong is assuming the material behaves identically—it doesn't.

Thermal expansion, humidity, and even the way a sheet is stored can warp a 300mm chassis rail by 0.3mm over a weekend. That's enough to bind a bearing block. Our community learned to specify material with a test coupon before any full run. Worth flagging—this adds a week to lead time, but it saved every batch after the first failure.

Why documentation from a single engineer often misses assembly steps

The faxed blueprint had nine pages. Beautiful hand-drawn isometric views, callouts for every bolt, and a BOM with McMaster-Carr part numbers. Missing: the order of installation for those bolts. The retired engineer knew you had to install the inner bearing before the outer spacer—otherwise the retaining ring won't seat. His fingers knew. His notes didn't. Most teams skip this: documenting what seems obvious to the original builder. Our first ten community builds required a group video call to figure out why the suspension arms locked up. The fix was flipping the washer order—a detail that never made it onto paper. That hurts when you have forty builders waiting for instructions.

The difference between a blueprint and a manual is the difference between knowing and showing.

— Community build lead, after the third support ticket about axle alignment

Now we tape-record every assembly session for new designs. Then we extract the "oh wait, do it this way" moments. It's imperfect but clear—and it beats the alternative of answering the same email thirty times. A single engineer's logic is linear. Community assembly is chaotic, simultaneous, and impatient. Document for the person who has never seen the part, not for the person who designed it. That alone cut our first-month return rate by half.

Patterns That Helped Us Turn a Sketch into a Product

Modular design principles that survived translation to manufacturing

The first pattern that saved us was a hard rule: every subassembly had to bolt onto the chassis frame without welding or custom brackets. I still remember the moment that paid off—we were three weeks from prototype delivery and a motor mount hole was 2 mm off. All we did was open the slot with a hand file. No re-cutting the frame, no angry call to the laser cutter. That sounds small, but modularity in a hobby design usually means “everything is adjustable with a Dremel.” That’s not modularity. That’s deferred pain.

We instead committed to a single rail width—20×20 mm aluminum extrusion—and designed every bracket around M5 fasteners. The catch is that this forced us to oversize several joints early on. A retired engineer’s sketch often uses bespoke standoffs because they look elegant on paper. But when ten community members each build one, and three of them grab M4 instead of M6 from their bins, you lose a day. We standardized on M5 countersunk bolts everywhere except the axle mounts. That trade-off—slightly heavier chassis, vastly simpler sourcing—kept the build logs consistent. Worth flagging: the first twenty kits shipped without a single missing bolt size. We had bet on boring hardware. It won.

— chassis lead, ultralyx v0.9 assembly team

Not every robotics checklist earns its ink.

Not every robotics checklist earns its ink.

Community review process that caught errors early

Most teams skip this: they design in private, then dump a PDF into Discord. We tried the opposite. Every Friday for four months, I posted the raw STEP file—warts, missing fillets, and all—and asked folks to load it into their own CAD viewers. The feedback was brutal. One member noticed the bearing pocket depth assumed a 6 mm lip; the actual budget bearings were 5 mm thick. That error alone would have made every wheel wobble after twenty hours of run time. But because he caught it on a Thursday night instead of a Tuesday production run, we fixed the step file in forty minutes.

What usually breaks first in these reviews is ego. Someone’s pet idea—like a three-piece clamping hub that looked gorgeous but required a custom broaching tool—gets defended. We killed that hub after three weeks of debate. The pattern that worked was: any part requiring a non-standard tool path had to earn its place with a documented build-time savings of at least two hours. That hub failed the test. The community’s willingness to say “not worth it” saved us a manufacturing nightmare. The pattern is not the review itself—it’s the rule that makes the review honest.

Using standard fasteners and off-the-shelf parts

Our first BOM listed sixty-seven unique part numbers. That's a disaster waiting to happen. We cut it to twenty-three by replacing custom spacers with nylon standoffs from McMaster-Carr and swapping a machined aluminum motor pulley for a standard timing-belt pulley with a 5 mm bore. The trade-off? The off-the-shelf pulley added 8 mm to the drive-train width. That pushed the wheelbase out by half an inch. But the cost per unit dropped by sixty percent, and any builder could replace a stripped pulley with a trip to the local hardware store.

The hard lesson: a perfectly optimized chassis that requires a specific Chinese factory run every time you break a part is not a product. It’s a prototype that got lucky. We deliberately left slack in the design—extra slot length on the motor plate, an elongated hole for the belt tensioner—because loose tolerances mean a builder can adapt without custom shims. That feels wrong to an engineer trained on interference fits. But for a community where one member builds in a garage and another in a university lab with a Bridgeport, slop is freedom.

The real pattern underneath all three? Design for the third build, not the first. The first chassis always works—it’s the tenth, built by someone with a rusty hacksaw and an hour of spare time, that reveals whether your patterns are real or just luck. Ours held. Barely.

Anti-Patterns That Almost Killed the Project

Over-engineering for hypothetical use cases

A lively online forum can be dangerous. Someone posts: "What if someone wants to mount this on a sailboat?" Suddenly we're adding stainless steel brackets, marine-grade sealants, and structural ribs for forces that would never hit a garage robot. I remember staring at a BOM that had ballooned by 40% — for features nobody had actually requested. We were building a tank, not a hobby platform. The reversion hurt: killing the "sailboat bracket" felt like abandoning a child. We cut three subassemblies entirely, swapped 316 stainless for 304, and lost exactly zero customers. The catch? We spent six weeks designing for edge cases that existed only in our heads. Next time: ship the simplest version, then listen.

Ignoring assembly order until the first batch

Wrong order. That was our first production meeting — ten builders staring at a pile of laser-cut parts, realizing you can't install the motor mount after the side panel is riveted. We had designed each component perfectly in CAD. No assembly sequence existed.

What usually breaks first is the human brain. People skip steps, flip fasteners, forget which bracket goes where. Our first batch required a full day of trial-and-error assembly just to document the correct order. Two builders nearly walked. We reverted by creating a single-sheet assembly map — one side, five steps, no optional paths. That sheet saved the second batch. It also revealed something embarrassing: our design had three redundant fasteners because nobody had asked "what order does this get built in?"

That hurts. A product designed in isolation assumes perfect knowledge. Real hands need a trail of breadcrumbs. We will never let a CAD-only review pass again without a physical run-through — even if it's cardboard and tape.

Assuming everyone has the same tools and skills

One builder had a drill press; another used a hand-crank drill from 1982. Our M5 clearance holes assumed a consistent 0.5mm tolerance. Reality: one community member's holes were oval, another's were undersized, and three people sheared bolts because their torque was guesswork. We specified "standard tools" without defining what standard meant.

Most teams skip this: the gap between a professional workshop and a hobbyist's garage is wider than the Pacific. We fixed it by adding a "minimum tool list" and redesigning three joints to use M4 thumbscrews instead of hex bolts. No special drivers. No torque spec. You finger-tighten until it feels right. That sounds sloppy until you realize it reduced assembly failures by 70%. The trade-off? Some builders wanted the precision of a machined fit — they got a design that tolerated slop. We lost two purists but kept thirty beginners.

'We spent hours debating thread pitch when we should have been asking who actually builds these things.'

— Community build lead, post-mortem meeting

Next time we survey tool access before the first prototype. A drill is not a drill. A workbench is not a workbench. Design for the lowest common denominator, then offer upgrade paths — not the other way around. That mistake almost killed batch one. It won't touch batch two.

The Long-Term Cost of Keeping a Community Design Alive

Inventory management for a niche product

We launched with 47 units. Six months later, 23 sat in a damp garage bay, three had been cannibalized for parts, and the remaining 21 were still boxed. Nobody predicted the connector shortage. The original engineer specified a JST-XH 3-pin that his local surplus shop carried by the kilo. Our community—spread across nine countries—couldn't source them without paying ten times the BOM cost. I have seen this pattern kill five other open-hardware projects. The trap is ordering enough to satisfy a Kickstarter spike, then bleeding cash on warehousing for the long tail. We locked roughly $3,800 in unsold PCBAs for eight months. That money could have funded two firmware sprints.

Honestly — most robotics posts skip this.

Honestly — most robotics posts skip this.

Most teams skip this: build a burn-down model before you order the first reel of components. Our mistake was assuming the production run would match the beta demand curve. It didn't. The first 100 units sold in four weeks; the next 50 took nine months. Meanwhile, a batch of custom aluminum enclosures sat untouched. Want to guess the storage cost for forty 10-kg boxes in a climate-controlled unit? $217 a month. That hurts.

Documentation drift as the original engineer steps back

The faxed blueprint was beautiful—hand-drawn, dimensioned to 0.1 mm, annotated with cryptic margin notes like "R7: do NOT substitute." Two months after launch, someone swapped R7 for a 1% 10 kΩ instead of the specified 5% 10 kΩ. The motor controller oscillated at 40 kHz. The original engineer, Paul, was unreachable—he'd taken a six-month sailing trip. Worth flagging: his departure wasn't hostile, just normal life. The community wiki had his reasoning scattered across three forum threads and a PDF with missing page 4. The catch with volunteer documentation is that nobody rewrites the manual until something breaks. By then, you're debugging at midnight with a forum post and a prayer.

“We spent 14 hours reverse-engineering a resistor value that Paul had solved in 1998.”

— Community maintainer, internal retro

That's the hidden tax: every undocumented assumption becomes a half-day of detective work. Over eighteen months, we logged approximately 220 hours of volunteer time on documentation triage. That's five work weeks of labor no one budgets for.

Support burden on volunteer maintainers

Wrong order. Not yet. The first support ticket arrived three hours after the launch email—a user whose stepper motor stalled at 72 rpm. We had eleven maintainers at launch. By month four, two were active. The rest burned out answering the same question about the power supply jumper. I fixed one ticket and watched five pile up overnight. The ratio was brutal: each active maintainer fielded roughly 40 messages per week. Build guides, troubleshooting, refund requests—one person spent a Saturday rewriting the soldering instructions for absolute beginners. That's noble, but it steals time from improving the actual product.

What usually breaks first is not the hardware—it's the humans. We lost a critical contributor because he spent three months answering emails instead of writing the motor calibration tool he actually cared about. A rhetorical question worth sitting with: is your community design burning goodwill faster than it builds it? If the support burden exceeds what three dedicated people can handle in ten hours a week, you need a paid triage layer or a drastically simpler product. We had neither. The seam blew out around month seven when a batch of faulty connectors caused 40% of new units to fail within two weeks. That one incident cost $1,200 in replacement parts and untold volunteer hours. The long-term cost of keeping a community design alive is not measured in components—it's measured in whether your maintainers still want to be there next year. Ours barely did.

When You Should NOT Turn a Blueprint into a Product

If the designer isn't willing to let go of control

We nearly killed our own product in month two. The retired engineer who sent that fax—brilliant guy, sketched the core mechanism on a napkin, had thirty years of pneumatic experience—couldn’t stop tweaking. Every Monday brought a new email: "Change the bracket thickness to 4.2 mm," or "Swap the fastener thread pitch, my test rig shows 3% better torque." Each change meant re-cutting aluminum, re-spinning the CNC operator, delaying shipments by a week. The community loved his passion. The bank account didn't.

The hard truth: a community design becomes a product only when someone says "freeze." If the original designer retains veto power over every dimension and tolerance, you never ship. You chase perfection on a single person’s mental model while customers refund their preorders. I have seen three other maker groups implode this way—one over a handle contour, another over a gasket material that existed only in the designer’s old lab notebook. The fix is brutal but clear: the designer must hand over decision rights to a release manager who doesn't care about the napkin sketch.

That sounds fine until you have to tell a respected mentor "your input is now optional." Worth flagging—some designers walk. And that’s okay. Better an empty seat at the table than a product that never lands.

If the community can't commit to support after launch

Most teams skip this: who answers the midnight help-desk ticket? The blueprint was free. The community loved it. But the moment we listed a price, the tone shifted. "My actuator arm binds on the Z-axis—fix it." "The BOM lists a discontinued switch—what now?" Nobody had signed up for tech support. We burned three weekends ourselves, unpaid, until we realized the model was unsustainable.

The pattern is predictable. Launch day enthusiasm fades. The core contributors who helped prototype drift to their own projects. New buyers arrive expecting warranty-level response, not hobbyist goodwill. If your community agreement—written or unspoken—contains zero clauses about post-launch maintenance, you're building a liability, not a product. We now require every product candidate to answer one question before we cut metal: "Who owns the inbox for six months after ship?" If the answer is "we’ll figure it out," the answer is no.

“A community product without a support plan is just an abandoned open-source repo with a price tag.”

— paraphrased from a builder who lost $12k on his own launch, 2023

If the design solves a problem only one person has

Retired engineers build for their own workshop. That’s fine—hobby projects are selfish by nature. But a product needs a market. We scanned the original blueprint and realized it required a custom 240V spindle that only existed in the designer’s garage. He had rewired his entire bench for it. Nobody else had. The first ten test builds required a secondary adapter that cost more than the rest of the machine combined.

Not every robotics checklist earns its ink.

Not every robotics checklist earns its ink.

The catch: the designer genuinely believed everyone worked like him. He had no reference point for a typical hobbyist’s tool stack, power constraints, or budget. We almost shipped a product that only made sense inside one room. The pattern repeats in every community—a clever solution that solves a very specific, very lonely pain point. How do you catch it? Build three units and give them to strangers. Don't instruct them. Watch what breaks. If they can't even plug the thing in without a call to the designer, the problem isn’t their fault—it’s yours for assuming universality.

One rhetorical test helps: "Would I sell this to someone I don’t like?" If the answer requires caveats, the design is probably too narrow. Our fix was brutal but direct—we redesigned the power interface for off-the-shelf parts and lost 8% efficiency. Painful. But the product shipped to thirty people instead of one.

Open Questions from Our First Product Launch

How do we handle version upgrades without fragmenting the user base?

Three weeks after launch, two different builds of the same blueprint started showing up in our forum. One member had swapped a servo for a stepper motor—better torque, sure, but it broke compatibility with every jig and bracket we'd published. Another user backported the change into the original design and posted it as "v1.2." Suddenly we had three living documents, no canonical source, and a growing pile of angry comments about parts that didn't fit. The catch is that locking the design kills improvement—but letting everyone fork it kills community. We still don't know the right cadence for official revisions versus experimental branches. Should we release a stable version every six months, or let the community vote on changes before we bless them? That debate filled forty posts and never landed.

Should we pay the original designer royalties or a flat fee?

The retired engineer who sent that fax didn't ask for money. He said "use it if you want." That sounds fine until the design starts selling. We offered him a flat $500 as a thank-you—but then someone pointed out that a 5% royalty would have paid him $2,300 by month three. Others argued royalties create perverse incentives: the designer resists improvements because better parts might lower margins. We've seen that split other projects wide open. Worth flagging—one member who'd been burned on a previous project refused to contribute to any future design that paid royalties at all. The question still sits open: flat fee respects a gift, but royalty respects ongoing value. Which message do we want to send?

What happens when the community disagrees on a design change? A simple question with no good answer. A member named Dave found that the original bearing housing collected dust in woodshops—a minor annoyance. He proposed a sealed bearing upgrade. Seven people loved it. Five said the change added $6 to the BOM and accused Dave of "scope creep." The thread got personal. We paused the change. Nobody was happy. The tricky bit is that design-by-committee tends to produce lowest-common-denominator results, but design-by-benevolent-dictator alienates the volunteers who make the community work.

We spent four weeks arguing about a bearing shield. In that time, three members built their own secret fork anyway.

— forum moderator, reflecting on a lost month

That hurt. The fork never merged back. The original design lost those members entirely. Maybe the right move is to let the community split into "official" and "experimental" tracks—but then you're managing two ecosystems, not one. Most teams skip this because it sounds abstract. It's not. It's the single largest time drain we face today.

One last unsettled question: who holds the authority to say "this is the real ultralyx design"? We printed the faxed blueprint and hung it on the wall. Some say that's the canon. Others say the first successfully built unit should be the reference. A third camp says the most-upvoted version on the forum is the de facto standard. Three definitions of "real." We need one. Pick a method, document it, and enforce it—or the community will decide for you, messily.

What We'd Do Differently Next Time

Start with a minimum viable batch, not a full production run

Our first order of business — we built fifty units. Fifty complete kits, stuffed into oversized boxes before a single builder had held a prototype in their hands. That was a mistake. We assumed the community would want what the engineer’s blueprint described perfectly. They didn’t. What they wanted was a working actuator arm, not a full chassis with five sub-assemblies nobody had tested together. The catch is obvious in hindsight: a hobbyist’s living room is not a production floor. What works on paper at 1:1 scale often breaks when you try to replicate it twenty times. We should have shipped a batch of three — a bare-minimum viable batch — and let the first testers break things on purpose. Instead, we absorbed rework costs on forty-seven units because the encoder bracket warped in a different plastic blend than the original prototype. That hurts. Next time, we treat the first run as a beta, not a launch.

Most teams skip this because it feels slow. “But the community is waiting,” they say. Waiting for what? A product that doesn’t fit their build environment? The v1.0 tag on a GitHub repo doesn’t mean the hardware is ready for real-world torque. We learned that the hard way — one builder’s garage had a different dust profile than the engineer’s clean desk, and the bushing tolerance closed up in two weeks. A minimum viable batch means you ship exactly what’s needed to validate the assembly experience, not the spec sheet. Three units, six builders on a shared Slack channel, and a two-week feedback window. That would have saved us four months of redesign and a pile of angry posts.

Create assembly documentation before ordering parts

We ordered the fasteners first. Then the PCBs. Then — as an afterthought — we asked the engineer to write down how the thing actually goes together. Wrong order. The documentation arrived in a dense PDF, page twenty-three of which described a screw length we had already bought in bulk. Too short by 4 mm. The thread locker was wrong for the aluminum subframe. We had to expedite a second fastener order at double the cost. The pattern here is brutal: parts lists are not assembly instructions. A BOM tells you what to buy, not why you buy it in that sequence. What usually breaks first is the step nobody wrote down — the trick of aligning the optical sensor while tightening the set screw, for example. That’s tribal knowledge that dies unless you force the engineer to record it while the prototype is still assembled.

We now insist on a build video before the first purchase order. It doesn’t need polish — a phone recording of the engineer assembling the unit in real time, narrating stupidly obvious details like “make sure the washer doesn’t fall behind the bracket” because that’s exactly where it will fall. Worth flagging — the video also exposes design flaws that a static blueprint hides. In our case, the engineer had to use a second pair of pliers to hold a nut that the drawing simply showed as “tighten.” That gap between the drawing and the reality is where your product dies. Documentation-first ordering means you catch the missing tool, the wrong torque, the incompatible lubricant before the parts are on a boat. It’s not glamorous; it’s the difference between a kit that works and a shelf of orphan hardware.

Plan for the original engineer to hand off maintenance early

The retired engineer doesn't want to debug your assembly line at 10 PM on a Tuesday. He designed a thing. He didn't sign up for a support job.

— Comment from our community lead after the third escalation call, post-launch

The trap we fell into was treating the original designer as the permanent reference point. He knew every fillet, every trace width. But his availability was sporadic — grandkids, volunteer work, a long-planned RV trip. When a builder hit a firmware glitch on the motor controller, we waited four days for an answer. The community forum filled with speculation, then anger, then silence. We had no backup documentation, no second engineer who understood the electrical side. That’s an anti-pattern that almost killed the project — key-man dependency on a person who never intended to be a product manager. What we’d do differently: schedule a three-month handoff period before the product ships. The original engineer records reasoning, documents edge cases, and explicitly approves a maintenance successor from the community. Not a vague “feel free to modify” license — a named person who can OK a bearing change or a voltage tweak without waking up the designer. The handoff should feel like a graduation, not an abandonment.

The long-term cost of keeping a community design alive is real. Someone has to answer the questions, update the BOM when a vendor discontinues a part, and decide whether a suggested modification is a bug fix or a feature creep. That someone can't be the retired hobbyist who just wanted to share a neat idea. Next time, we build the maintenance crew before we build the product. Specific next action: create a rotation of three maintainers with write access to the hardware repo, each with a defined domain — mechanics, electronics, documentation. The original engineer stays as an emeritus advisor, not the frontline responder. That structure would have cut our response time from four days to four hours. And it would have preserved the community’s trust, which is harder to recover than any hardware revision.