Overview
Sales Diary is an offline-first mobile app for digitizing the data collection processes used by eFishery's field sales to record their activities, such as payment collection, record lead data for acquisition, and product order requests for fish/shrimp farmers they visited in remote areas. The data collected is used for internal analytics and business development teams to help them generate higher sales conversion rates
I joined the team to help build the product to scale the app architecture and solve performance and reliability issues. This project became one of the most challenging works of my career, not just because of its unique case as a user-facing app, but because of the depth of the problems, ensuring it remains functional when accessed from rural areas
Key Challenges
- Ensuring reliability in rural areas with little to no internet connection
- Preventing duplicate data sync after connectivity spikes
- Improving form validation for complex lead data
- Making the UI feel familiar, even though the design isn't very good
How I Overcame Them
It was my initial experience developing an offline-first application, which must be dependable in rural areas that present unique obstacles, such as the need to record data when there is little to no internet connection. I had to learn on the fly about how the app saves data, syncing between remote and local data from the device, and how to deal with duplicate data that is being saved accidentally when the connection gets a spike
Improving the Functionality
I was asked to improve its lead acquisition feature, which is basically just a form input with so much data needing to be filled, but it lacks solid validation that leads the data collection not to be good enough for the data team to process
The other challenge was the UI, where it doesn't feel intuitive enough due to its UI design; it was translated from a low-fidelity wireframe, which confuses the user. Not only UI, but also its performance is not good enough, like it has untraceable errors and compatibility issues on some devices. But since it was developed pragmatically in the first place, I focused on its functionality and eventually improved its usability and ensured the app doesn't crash
I succeeded in improving the feature by implementing a better form validation, refactoring the code to colocate its state management that makes the code more readable, and preventing flaws on the UI that can make the user submit duplicate data
Chance to Rewrite the App from Scratch
My lead had an idea to rewrite the app from scratch since it feels bloated; some of the concerns are that the code isn't maintainable, they wanted to use a UI library to have better visuals, and the legacy code was challenging to understand. I got the opportunity to write it from scratch, build components that align with design system guidelines for React Native, and decided to introduce a more predictable state pattern using Context-Reducer for form inputs, improving consistency and reducing unnecessary re-renders. I also developed a better flow for preventing the submission of duplicate data by saving the data to draft before sending it to the remote server so it's always synced correctly. By doing the rewrite, I also implemented better logging for errors using Sentry so I and the team can catch errors easily and more accurately, I succeeded in improving the crash-free rate from 70% to 95%
What I Learned
Sales Diary taught me how to make a reliable app when there is little or no internet connection and also think about its performance, especially on various devices that the field sales have. It was a unique real-world problem that I might not think about, and I had to think about trust, empathy, and scale all at once. I learned how to build an app with scalable architecture, the value of designing for performance, aligning with the product team and the users, and understanding the pain points from the users by reaching them directly to ensure its usability