Turning smartphones into remote controls for a nationwide network of self service kiosks

PROJECT OVERVIEW

ABOUT THE CLIENT

This case study is based on a real VNEXT project. The client's identity and certain project details have been anonymized or generalized for confidentiality purposes.

Our customer has spent decades putting self service machines where people already are, with thousands of locations around the country. It began with automated photo booths and has been widening its range ever since, adding services such as vending and laundry through a new generation of machines. A network like that is built on convenience, and as it grows, the question becomes how a customer discovers each new service and why they come back to use it again. Exact financials are withheld for confidentiality.

THE CHALLENGE

The customer wanted a mobile app that would make its different machines feel like one service. That is an easier sentence to say than to build, because a mobile app is one of those products that people understand best when they can hold it. The customer's team knew its machines and customers thoroughly, but a new app was a different kind of conversation, and the details of how it should work had to be discovered together instead of described up front.

The people involved also reached beyond a single team. Four parties contributed to the project: our team, the customer, and two development teams working for the customer. Keeping information moving evenly between all four, and keeping everyone's progress visible, is a project in itself.

Finally, the app had to talk to real machines. A photo booth and a vending machine each behave in their own way, and they live out in the world rather than inside our test environment. Connecting a phone to a physical device is the point where a polished app either feels magical or falls flat.

PROJECT OBJECTIVE

Our customer wanted its newly registered users to be able to find the right machine, use it with the help of their phone, and earn reward points that they could spend later. It also wanted the whole thing, from requirements to the running server, delivered by one team that understood how the pieces fit together.

APPROACH AND METHODOLOGY

Showing the app before building it

Because the customer's team could judge the app better by seeing it than by reading about it, our team built clear prototypes early and used them to confirm each requirement. Along the way we suggested the technologies that fitted what the prototypes showed, which kept technical choices connected to what the customer actually wanted rather than to a specification written in the abstract.

Giving four parties one place to communicate

With four parties involved, our team proposed a formal communication channel that everyone used for sharing information. A single, agreed place for decisions meant that progress was easy to follow, that nothing important lived in a private conversation, and that each team could plan its own work with confidence.

Connecting machines one model at a time

Integrating with physical machines was the part with the most unknowns, so our team divided the work into stages and let each stage cover a single machine model. That approach turned a large question into a series of smaller, answerable ones. By the end of the first stage, how a machine really behaves was clear, and what had been learned could be applied to the others.

Protecting the data from the start

Our customer required that its production database could be reached only by its own people. We enforced that by setting database permissions with AWS identity and access management, so the rule was built into the infrastructure rather than left as a policy to remember.

TEAM SCALE

Our team for this engagement numbered up to eight, covering the full path from requirements to a running service.

• Project manager: planned and drove the project, and proposed technical solutions to the customer's requirements
• Business analyst: wrote the business and system requirement documents
• Mobile developer: built the Android and iOS app in Flutter and shaped the mobile side of the technical design
• Backend developers: built the management web application and the API in PHP and VueJS
• Quality lead and testers: reviewed designs, wrote the test plan, and created and ran test cases to keep quality high

THE SOLUTION AND TECHNOLOGY STACK

The customer ended up with an app that behaves as a front door to its machines: it helps people find them, work with them, and be rewarded for returning.

What was built

• Sign in and onboarding: lets new users register with email or sign in with a social account
• Home and service discovery: puts the customer's different services, such as photo, vending, and laundry, in one place
• Machine matching: shows nearby machines on a map and matches each user with the machine that fits what they want to do
• Direct connection to machines: connects the app to a machine in real time, so that choosing a photo and tapping Print on the phone sends the photo to the booth to display for printing
• Rewards: lets users earn reward points and use them
• History: keeps a record of what the user has captured and used
• Management web application and API: gives the customer's staff a back office and supplies the data that the app depends on
• Server design, implementation, and operation: covers the cloud environment that runs everything

Technology Stack

THE RESULTS

Machines that once waited for customers to come to them now meet customers on their phones.

• One app across different kinds of machine: customers can discover and use photo, vending, and laundry services without learning a separate system for each
• A phone that works as the remote control: choosing a photo on the app and tapping Print sends it straight to the booth, removing steps that used to happen at the machine
• A reason to come back: reward points earned and spent through the app give customers a direct incentive to return
• A foundation that extends to new machines: learning how one machine model behaves made it much easier to connect the others, and the same approach is ready for machines the customer has not launched yet
• Customer data under the customer's control: access to the production database is restricted to the customer's own people, through permissions built into the infrastructure

For a business whose strength is being everywhere, an app that makes every machine easier to find and more rewarding to use turns a physical network into a relationship with each customer.