Rethinking Harvest's Mobile Strategy

Harvest is a time tracking application for professional services teams. Launched in 2006, Harvest attracted a loyal customer base who rely on it to track billable hours, invoice customers and provide critical insights into their business. Harvest was acquired by Bending Spoons in 2025.

In 2020, I joined Harvest to lead engineering and help scale the business. Although this was at the start of the global pandemic, Harvest was already a remote-first business so my first 100 days were not affected by any changes in operation. The product engineering team was comprised of frontend, backend and native mobile engineers. Harvest itself was a monolithic Ruby on Rails application supporting thousands of users. At the same time, a new VP of Product joined and we collaborated on revising and prioritizing the product roadmap.

The Mobile Challenge

One of the bottlenecks we identified as we restarted feature development was that our mobile applications were not only lagging behind desktop and Web but they lacked feature parity with each other. At Harvest, the Web application is the primary surface that customers use. We used Electron to build the desktop application which, in turn, reused the majority of the Web frontend. However, the mobile applications were built with native code for Android and iOS. We had one full-time engineer building the Android application and the iOS application was primarily worked on by a part-time contractor with support from the engineer working on the macOS application.

As part of my initial listening tour, I asked about the decision to build native mobile applications. Harvest is a time tracking application and is mostly forms and reports. The timers are maintained server-side so it was not clear why the bulk of the application required native code. The majority of the product engineers were Apple fans who internalized Apple’s philosophy about building mobile applications: go native. This also explained why features appeared on iOS well before they were delivered on Android.

My first instinct was to direct the team to turn Harvest into a Progressive Web Application and radically simplify our platform development and support. However, customers expected to get their mobile apps from an app store and wanted a native app experience. This led me to propose evaluating React Native as an option for building our mobile applications. The majority of the team was open to the idea, but there were a few skeptics: the iOS contractor and our VP of Product. Both were concerned that we wouldn’t be able to deliver a comparable experience with React Native. So, my first step was de-risking.

Time Well Spent

Engineers love building greenfield applications especially if they get to explore new technologies in the process. Harvest had previously conducted an interview series in conjunction with Creative Mornings called Time Well Spent. Each interview included a pie chart showing how the interview subject spent their time. Harvest provided a PDF template for people to create their own Time Well Spent charts. This felt like a great opportunity to build a new, focused mobile application using React Native.

We quickly put together a quick project brief for the Time Well Spent app, including the ability to share pie charts on social media. After a couple of weeks spent setting up the toolchain and working through tutorials, the team was able to build the application in short order. The application looked great, worked well and delivered feature parity with one codebase. Still, this was a proof of concept built as a learning exercise. Now, we had to prove that we could deliver an experience that was comparable to the native Harvest mobile applications.

One View At A Time

Our next step was to replace a native view in the existing applications with a React Native replacement. We started with the Account Settings view to work through the basic mechanics that would be required. It was as straightforward as we expected so we shipped it. The next view, Timesheets, would give us the signal we needed. It was one of the more complex views in the application and would allow us to better assess performance and responsiveness. The team immersed themselves in the implementation and made use of the wide range of community resources to resolve problems as they arose. Once they achieved feature parity with the existing Timesheets view, we had the whole company install the TestFlight build and stress test the application on both Android and iOS for a few weeks. We successfully addressed our internal skeptics’ concerns about using React Native. However, we were far from finished.

A Brand New Harvest

In addition to restarting feature development, our VP Product had kicked off another big initiative: a brand refresh. This would be the biggest change to Harvest’s visual identity in its history. The primary goal for end of Q1 2022 was to completely revamp the marketing website and related resources. We would take a more incremental approach to updating all of the applications, including mobile, for the rest of the year.

My push for React Native was motivated by more than making it easier to have feature parity in our mobile applications. Harvest was an application born on the Web and we employed talented Web developers with extensive domain expertise. They just couldn’t contribute to our mobile applications. We would soon need them to because both our Android engineer and iOS contractor gave notice within a few months of each other. Luckily, as we started building views incrementally other engineers started learning React Native to expand their skill sets. We also had hired an experienced React Native engineer who was more than happy to help his teammates level up.

We now had a partially migrated mobile codebase, a brand refresh and team changes as potential risks to launch. We had set a feature complete target for November which coincided with the company summit. The idea of previewing the new application to customers and partners motivated the team and they proceeded to reimplement every view in the application according to the new design system. By November, our Android and iOS applications were completely implemented in React Native. They officially launched, together, in January 2023.

Conclusion

The journey of reimplementing Harvest’s mobile applications using React Native was more than just a technology stack upgrade. Moving to React Native provided Harvest leverage. Switching technology enabled faster feature development with parity across platforms while also eliminating the need to employ platform-specific engineers that were mostly under-utilized. Those two factors helped make Harvest a more efficient business.