For a global corporation, a four-year R&D partnership that turned open questions about field data collection into two Android applications running in production – built hypothesis by hypothesis, each one validated or discarded before it became expensive.
Client
An undisclosed large, global corporation. Field data collection is an internal process there rather than a project – employees gather large volumes of data away from a desk, and the quality of what reaches the company's systems depends on how well they are able to work while they do it.
Delivering into an organization of this size means the applications have to sit inside a data pipeline that already exists and is already owned by internal engineering teams. It also means they have to hold up in field conditions, where a tool that demands attention costs more than it contributes. Software that passes review is not the same thing as software people still reach for on the hundredth day of using it.
Problem
Our client had an internal process to gather large amounts of data in the field. Any improvement in an employee's focus and productivity out there contributes to the quality of the data gathered – which makes the process a worthwhile place to invest, and a difficult one to write a specification for.
The client was not looking for a vendor to implement a defined system. They were looking for a partner combining two unique strengths – an ability to provide research & development work and UX discovery alongside mobile development skills – and able to apply them to a question stated at the broadest possible level.
What can we do with affordable mobile technology to help them?
A question in that form cannot be estimated, only explored. That puts a particular demand on the vendor: to run an open-ended program without it drifting, to keep producing findings the business can act on, and to say plainly which ideas are not worth pursuing further. As research and development is not your typical run-of-the-mill project for a custom software development company, we assembled a mobile team under the guidance of Iwo Herka, our Principal Software Engineer.
Our modus operandi was to work directly with users to design, prototype, test, and refine features quickly in tight feedback loops. This way, we were able to sift through many ideas to find the best ones.
Iwo Herka, Principal Software Engineer
What we did
We broke the big questions down into testable hypotheses and built proofs of concept against them, validating as fast as possible whether a direction deserved to go further. The aim was not to build quickly – it was to find out quickly, so that effort concentrated where it would return something.
Android was the chosen platform, as it offers more variety in device choice, which was better suited to what the company needed to put in employees' hands.
From the hypotheses we developed in partnership, we delivered two larger mobile applications and a toolkit of smaller ones that support the data-gathering pipeline and integrate the two main applications into it.
The first optimizes processes the company already ran. Its user experience, built by Justyna Papiernik and then improved iteratively with the field employees who use it, was the substance of the work rather than a layer applied over it – for a tool used in the field, the interface is the product. It went into production environments and stayed there, which is the real measure of the cooperation.
The second expanded what employees were able to do rather than making existing work faster. It ran operationally for years, with feedback arriving every few months and shaping each subsequent round of improvements.
Crafting those apps was a miracle of embracing corporate strategies, capturing what is unsaid in work, translating it, and rebuilding in the language of a user interface, often pushing the limits of the human-computer interactions as we know them.
Justyna Papiernik, head of UX
Timeline
Cooperation began in 2019, with the first hypotheses validated within the opening months. Through 2020–2022 we built the two larger applications and tested them extensively before they entered production. Support and iteration continued from there until the program was wound down in 2023 – four years of continuous responsibility for tools the company's field work depended on.
Across that span the client relied on us to organize the work internally and report on it clearly. For a program with no fixed specification to measure progress against, that reporting mattered as much as the delivery itself.
Technology stack
- Android
- Kotlin
- RxJava2/3
- Dagger 2 (dependency injection provider)
- Android Room
- Resilience4j
- stateless4j
- Google Firebase
- Retrofit
- Client's proprietary APIs
- Elixir
- Cowboy/Plug (HTTP server)
- JavaScript
- Vue.js
- Python
- Flask
Effort concentrated in three areas, each of them a consequence of where the software would end up running:
- fault tolerance – the architecture was adapted to stay resilient to external factors it does not control, backed by extensive testing and environment mocking, with feedback loops introduced wherever they shortened the path to knowing something had broken;
- usability – the applications would be used in field conditions, where anything that distracts costs more than the feature that caused it;
- low technical debt – the applications are complex, yet had to remain operable for years, so debt was held down throughout development rather than deferred to a cleanup phase that may never be funded.
A tool that helped a lot in the development of fault-tolerant software was the use of state machines, which we used to define possible states, transitions between them, and output events. Without FSM, it would be very difficult to handle many different states and edge cases and to observe if they are correct.
Elżbieta Hofman, Android Developer
One of the biggest architectural challenges was to make a scalable, loose-coupled system that could accommodate change while the project was growing rapidly at the same time. We achieved that goal, and it allowed us to produce a system that is more customer friendly and easier to be tested and maintained.
Mateusz Łuczak, Android Developer
Our unique contribution
In Makimo, our unique contribution always comes from the combination of a few factors rather than any single one of them.
In this case study, it was:
- augmenting the internal engineering team with relevant UX & mobile skills to build a synergy with the backend teams that already owned the pipeline;
- understanding, then delivering – a key promise when doing research & development work, where building the wrong thing efficiently is the expensive failure;
- building applications with resiliency in mind – because adoption of such software depends on it being a reliable partner of the user, not on its feature list.
That blend is what carried the cooperation through four years, and what brought it to a planned close rather than an abandoned one.
Heroes of the story
Iwo Herka · Justyna Papiernik · Elzbieta Hofman · Mateusz Luczak · Kamil Supera · Daria Grochowska · Bartlomiej Zak · Mateusz Papiernik · Michal Moroz · Wojciech Mielczarek · Dmitrii Chernikov · Kamil Kucharski · Marcin Strus · Aleksander Krawiel
