The Part That Looked Clever Broke

The early guide rods ended in flexible split clips. In the model, the clips were tidy: push each one through the lid and let the barbs retain the cap from below. In the physical assembly, the clip roots fractured.

That failure led to 5 more revisions of the cap. The current cap uses solid 6mm pins with narrower 4mm spigots at the ends. Separate collars slide onto those spigots after the rods and springs pass through the lid, then glue in place. It adds four tiny parts and an assembly step, but removes the thin flexing roots that were carrying lateral load in the printed orientation.

I also added a true 0.6 mm-radius fillet around the entire joint where each guide rod meets its shoulder. That is a small change in Fusion 360 and a meaningful one in plastic: the rounded transition removes the sharp stress concentration where the earlier rods wanted to snap if I really hammered on it.

Testing the model in CAD might show some real friction, but sometimes the only way to iterate an improvement is to use it past the point of failure.

Designing the Enclosure Backward

The cap hides almost the entire top of the lid. That makes top-installed enclosure screws easy to draw and annoying to service: once the button is assembled, the cap blocks access to them.

The revised enclosure fastens entirely from the bottom. Four M4 machine screws sit in recessed pockets under the base, pass through shortened posts, and thread into heat-set inserts installed upward into reinforced bosses on the lid. The screw heads stay above the desk surface, and the lid can be removed without dismantling the moving cap.

M4 was not an arbitrary hardware choice. M5 inserts would leave too little plastic around the existing corner geometry. The design includes a small insert test coupon with 5.6, 5.8, and 6.0mm entry diameters because the correct heat-set fit depends on the insert, filament, printer, temperature, and shrinkage. Printing the coupon first is cheaper than discovering the wrong fit in a long enclosure print.

The Electronics Are Intentionally General

For the prototype, I used a Waveshare ESP32-S3-Zero. It is small enough to disappear inside the enclosure, and its native USB connection lets it behave like a keyboard without a separate USB interface. Wi-Fi and Bluetooth Low Energy are already on the board for whatever the button becomes next.

The RGB run is deliberately short so the button can stay within a sensible USB power budget. The pixels share ground with the controller, and a small series resistor on the data line is cheap protection for the first pixel. If the lighting grows beyond a handful of pixels, it deserves its own power calculation instead of assuming the USB port will carry it. In all transparency, I was not running RGB until the last iteration. I'm not a huge RGB guy, but it had a small strip, so I went with it.

One press can play a light animation and type a key sequence. It could also call an HTTP webhook, publish an MQTT event, trigger a Home Assistant scene, or use short, double, and long presses for separate actions. Change the logo insert and firmware, and the same enclosure can become a build button, push-to-talk control, recording marker, accessibility switch, help-desk alert, or a branded interactive display.

That is the part I like most. Software normally hides behind a screen full of equally weighted controls. A physical button does the opposite. It declares that one action matters enough to have a place on the desk.

But what was the point?

Nobody needs a 100mm button to create a Laravel project. That is why it is fun. But novelty does not excuse a mechanism that binds, a switch that takes structural abuse, or an enclosure that cannot be serviced after assembly.

The project ended up following the same pattern as good software work: make the boundary clear, keep the irreversible action under human control, test the smallest risky assumption first, and let failures change the design instead of explaining them away.