Enough Stores Retail Ltd, a UK startup developing sustainable retail technology and IoT-enabled dispensing systems.
My official role was Software Engineer and my scope was full stack. I developed the data-driven web application and modular Python/Flask APIs that connected customer actions, stored operational data and embedded hardware workflows.
The engineering problem
The product needed to translate a customer’s selections into a dependable physical dispensing journey. Unlike a conventional web application, an accepted request could initiate real-world device behaviour, so validation, workflow state and recovery paths mattered beyond the HTTP response.
I joined without prior IoT experience. I had to learn the domain quickly while contributing across the browser interface, API layer, persistence and device-integration boundary.
Architecture at an appropriate level
customer journey
rules + validation
operational state
controlled commands
The interface captured customer choices and displayed progress. Flask services owned application rules and persistence. A separate device-integration boundary translated validated workflows into controlled hardware operations.
What I contributed
- Developed the data-driven front-end web application and its Python/Flask backend APIs.
- Engineered modular API workflows supporting customer setup, product selection and automated dispensing.
- Integrated application logic with embedded hardware components without exposing device-specific complexity to the web layer.
- Persisted operational state required for first-time and repeat customer journeys.
- Diagnosed issues across software and physical-device boundaries while becoming productive in a previously unfamiliar IoT domain.
Key engineering decisions
Model the product workflow, not individual components
APIs organised around customer and dispensing workflows.
A user interface directly issuing unrelated low-level hardware commands.
This kept business rules within the application layer and reduced coupling between the customer interface and proprietary device implementation.
Separate responsibilities
Clear boundaries between interface state, API logic, persistence and device integration made failures easier to locate and reduced the impact of change across layers.
Represent physical progress explicitly
A command being accepted is not the same as a physical workflow completing. Designing around meaningful intermediate states made the system easier to reason about and recover.
Outcome
The work delivered a functioning full-stack bridge between a customer-facing web journey and an IoT-enabled dispensing system. It demonstrates backend API design where software correctness influences physical behaviour, without disclosing proprietary hardware or implementation details.
What I learned
- Physical systems need explicit state, validation and safe recovery paths.
- Modular boundaries make cross-layer faults easier to isolate.
- IoT engineering starts with the real user journey, not individual device components.
- Structured learning and experimentation can close an unfamiliar technical-domain gap quickly.
- Full-stack ownership is valuable when it preserves one coherent system.