Another festival, another change
A beer dispensing startup kept adapting its machines for each new event.
The situation
A hardware startup was developing a self-service beer dispensing machine for large festivals and events. After building an early prototype and securing investment, the founders began deploying machines at festivals.
The initial deployments helped them attract paying customers and learn how their machines performed outside the workshop. But each new event also brought different requirements, and the team needed to decide how to accommodate them
The plan
The founders took an iterative approach, improving the machines between deployments based on what event organizers needed.
Some festivals used different payment providers or wristband systems. Others had their own reusable cups, which required changes to the dispensing mechanism. The team worked through these requirements to make each deployment possible.
With a small engineering team, weekdays were spent developing and modifying the machines, while weekends often involved supporting them at events. This allowed the company to continue serving customers and learning from each deployment.
Where uncertainty remained
As the number of deployments grew, so did the engineering work needed to support them.
The reusable cups became a particularly difficult challenge. Changes in European regulations had pushed festivals toward reusable containers, but different venues used different sizes and designs. Developing a mechanism that could reliably separate and dispense these cups proved much more complicated than anticipated.
The founders were gaining customers and improving the product, but they had limited time to consider how the growing number of requirements would affect the system's longer-term scalability.
What needed to be proven first
Looking back, one of the founders believed they could have progressed faster by spending more time considering what the product would eventually need to support.
They had always intended to serve large events, but hadn't fully translated that ambition into a set of longer-term product requirements.
Understanding the range of payment systems, cup designs, and operating conditions they would encounter could have helped them make more deliberate architectural decisions earlier.
At the same time, the deployments themselves had been essential to discovering those requirements. The opportunity was to use that learning to guide the broader product direction rather than allowing each upcoming event to determine the next engineering priority.
The pattern
Customer deployments reveal requirements that are difficult to anticipate during development. But when every new request drives another design change, the product can become increasingly difficult to standardize and scale.
At Hardware Velocity, we work backward from the intended product and business model to identify the requirements that should guide development. This helps founders learn from early customers while making engineering decisions that support where the product needs to go.