From Hardware Button to Spotify Control: Designing a Simple Yet Fragile Sys

The original goal was intentionally minimal:

• Press a physical button

• Trigger a command

• Control Spotify playback remotely
  
  

No screen.
No UI flows.
No companion app.

Just one physical action mapped to one digital outcome.

This constraint made the project useful — not as a product, but as a system design exercise.

The earliest firmware logic was straightforward:

• Detect press

• Send request
  
  

But real usage quickly exposes edge cases:

• What if the button is held?

• What if a previous request hasn’t finished?

• What if Wi-Fi is temporarily unavailable?
  
  

A stateless design feels clean, but becomes fragile the moment timing and retries matter.

📋 Key takeaway: Even minimal systems need explicit state management.

Network reliability is often assumed, not designed for.

Common failure modes include:

• Wi-Fi reconnect delays

• DNS resolution issues

• API request timeouts
  
  

From the user’s perspective, the button still clicks—but nothing happens.

This mismatch between physical feedback and system reality erodes trust quickly.

📋 Key takeaway: Any network-dependent system must assume the network will fail.

Controlling Spotify involves more than sending a command.

Hidden requirements include:

• Valid authentication tokens

• An active playback device

• A compatible playback state
  
  

If Spotify isn’t already playing on a device, commands may succeed technically but fail functionally.

The system believes it worked.
The user hears silence.

📋 Key takeaway: APIs report technical success, not user satisfaction.

This system spans multiple domains:

• Physical hardware

• Embedded firmware

• Network infrastructure

• Cloud APIs

• Third-party application state
  
  

Each layer is reasonable on its own.
Together, they multiply uncertainty.

This fragility isn’t a mistake—it’s a property of cross-layer systems.

If this were a production system, improvements would include:

• Clear feedback mechanisms (LEDs, sound, haptics)
  
  

• Retry and timeout strategies
  
  

• Explicit offline handling
  
  

• Playback state validation before issuing commands
  
  

⚡Most importantly⚡

  "A simple interface does not mean a simple system."

• ➡️ SYSTEM REVIEW｜How to Design for Failure in Small Systems
  
  

• ➡️ BUILD LOG｜Router Alerts: Turning SMS Signals into Reliable Notifications
  
  

• ➡️ FIELD NOTE｜Self-Healing Wi-Fi in Real Environments
  
  

• ➡️ Architecture & Technical Review｜What to Review Before Shipping a “Simple” System