Client: manufacturer of industrial vending machines · Engagement: 2-month proof of concept (4 sprints), followed by a full next-generation platform · Model: SaaS · Delivered by i4B
A manufacturer of vending machines for factories wanted a new SaaS platform, but earlier software projects had left it wary of unpredictable costs. Instead of a big build, we ran workshops to name the business and technical drivers, then a two-month, four-sprint proof of concept on a pre-production environment. It delivered measurable gains in machine synchronisation, load-test observability and a draft TO-BE API architecture, and it earned the trust for the full platform that followed.
Project context
Our client builds vending machines installed in factories. Workers use a card to take what they need for continuous work, such as gloves, glasses or drills. The factory does not have to keep local stock or pay in advance, workers get items just in time, and limits stop anyone from taking too much too often.
The client was considering a new SaaS platform for factories, workers and the suppliers of the goods stored in the machines. Bad experiences with software projects in the past had left them unsure about predictability of costs and return on investment. So we suggested starting with three questions: what should the new platform change, what are the business and technical drivers, and which hypotheses can we test quickly?
Business and technical drivers
A few workshop sessions showed that the main beneficiaries were the goods suppliers and their warehouse agents, the people responsible for business growth on both sides. Serving their needs set the architecture and infrastructure demands.
- Business drivers
- High availability, stable performance, and reliable data for predicting costs, revenue and sales of the items stored in the machines.
- Technical drivers
- Scalability, continuous integration and deployment with zero downtime, strong data security, awareness of infrastructure costs, and testability.
- Risks
- Load tests could burn cloud resources quickly, so the team would alert the client to any sudden cost increase. Experiments needed room to go deeper. Unplanned leave, especially on the client side, could weaken communication. And because this was R&D, we agreed to change sprint scope, normally avoided in Scrum, only when our findings justified a change of direction.
Proof of concept setup
A dedicated i4B team with a proxy product owner, a business PO and technical leader on the client side, and sprint goals clear for all four sprints. Sprint Shift = demo and review, mini-retro and planning in one session.
Key results of the PoC
Over two months of agile work, adjusting direction, refining the backlog and showing live results on a pre-production environment as early as possible, we improved synchronisation, initialisation and data exchange between the management platform and the vending machine operating system, and improved the numerical parameters of requests.
The team visualised synchronisation load against the stability of the new architecture, monitored reaction time as load increased and left a ready synchronisation test environment. Prepared load tests and metrics made the new API's responsiveness observable during machine synchronisation, opening the way to reports and alerts. We also drafted the TO-BE API architecture and its infrastructure components.
Inside the architecture
Technologies and practices
Outcome
Beyond the artefacts, the PoC delivered trust, proven predictability and tested cooperation.
That was a solid foundation for the proper new project: a full next-generation environment for the vending business. It covered persona identification, customer journeys, user story mapping and cutting the scope for an MVP, a proof of concept for infrastructure and architecture to keep risk low, and more than 30 sprints of development.
Key terms
- PoC
- Proof of concept: a short, time-boxed project that tests the riskiest hypotheses before committing to a full build. Here, four sprints over two months.
- Proxy PO
- A product owner on the i4B side who works with the client's business PO and keeps the team's backlog aligned with the client's goals.
- Sprint Shift
- Our three-hour biweekly session that combines demo and review, a mini-retrospective and planning for the next sprint.
- Zero-downtime deployment
- Releasing new versions without taking the platform offline, a requirement in factories where every minute of delay counts.
Frequently asked questions
Why start with a proof of concept instead of building the platform?
The client had bad experiences with unpredictable software costs. A four-sprint, two-month PoC tested the key hypotheses on a pre-production environment, showed measurable results early and proved that our work was predictable before the full platform was commissioned.
Who were the main users of the new platform?
Workshops showed that the goods suppliers and their warehouse agents were the main beneficiaries, because they drive business growth on both sides. Factories and their workers also use the platform.
What happened after the PoC?
It led to the full next-generation platform for the vending business, which started with personas, customer journeys and user story mapping to cut an MVP, and continued for more than 30 sprints.
