How to replace an inherited third-party app with one everyone love
This post was originally posted in Funding Circle's Engineering Blog on August 15, 2016. Co-authored with my awesome colleague Emma Makinson.
Some time ago, together with the Product and Design teams at Funding Circle, we started thinking about refreshing the whole user experience for Funding Circle investors - starting with the mobile app. We had an existing app for iPhone and iPad, written by an external agency in 2013, but it couldn’t meet our investors’ needs and was increasingly difficult for us to maintain.
This August, after many months of careful planning and hard work, a second version of our iPad app was released to Funding Circle investors. In doing so, we brought the iPad app up-to-date with the iPhone app we released at the end of last year, and were able to completely remove the earlier version of both apps, which we’d been supporting for three years. Along the way, we’ve learned a few things about rebuilding applications - this is our perspective on when you should do it, how you should do it, and what you can expect at the end of it all.
When should you rebuild an inherited application?
When you keep running into problems
There were multiple reasons for rebuilding the iOS app from scratch. For a start, the app felt old and users frequently suffered random crashes that were difficult to debug. The codebase also needed to be brought up-to-date with new technical requirements: it used deprecated Apple APIs, and supported four different versions of iOS. The original app was also created on a moving surface with the API changing constantly and not taking into account the mobile needs. Finally, the existing code was hard to maintain and did not reach the standard we wanted: some areas of the codebase were duplicated; everything was tightly coupled; and there were no tests across the whole app.
There is nothing wrong with having an external agency build your application. It is a quick way to market, and it allows you to take a pulse of what your users really want from it before you invest more heavily in the product. However, maintaining an externally-written app can be expensive in the longer term. Ultimately, great apps need dedicated specialists (developers, designers, etc.) and great design takes time to work through.
When you’ve first tried to improve it
We did not take this decision lightly, and we were conscious of how rewrites can seem very exciting and then easily go wrong, so we first tried to stabilise and improve the existing app instead. We added Crashlytics and, for three months, we worked hard on optimizing the network requests and fixing all the major issues causing crashes to our users. At the same time, we introduced functional tests across the app, so we could make sure that we were not breaking anything. In three months, we managed to increase the percentage of crash-free users by more than 20%, but there was a lot of work still to do, making any change took far longer than it should, and we hadn’t been able to deliver any new features.
When the existing product will hold you back
After working with and exploring the codebase for three months, representatives across Product, Design and Engineering felt that the existing codebase was no longer fit for purpose, and that we should not try to extend it.
While we did not want to replicate all the functionality of the desktop site, we wanted to be able to provide lots of new features as well as small delights for our users, from offering simple conveniences like Touch ID, to delivering different views and experiences for different screen sizes, to keeping up-to-date with standard UI conventions. Rebuilding the application seemed to be the obvious step, if we really wanted to achieve all these big ideas we had in mind and to transform the way our users engaged with us.
How should you go about it?
Listen to your customers
We decided that if we were going to redefine the way our customers interacted with Funding Circle, we should ask them what they wanted.
When thinking about mobile, it is easy to make the common mistake to try to match the same features that you offer on the desktop site, when in reality mobile users have different needs and different preferences. You should see mobile as an extension to your desktop experience, instead of a replacement.
We focused on content first and took the approach of building constant prototypes, validating them with our customers and iterating over them until we got the user experience right. This was an exhausting but very enlightening effort that the Design team drove, but in which the whole team participated. The true value was not only in getting a better sense of what users want to do when they open the Funding Circle app on their smartphone, but also in making sure that everyone in the team understood why we were doing things the way we were doing them, so that we all knew the reason behind every single decision.
Work closely with the rest of the business
As developers, we’ve worked closely with the design team and the product team to build the app. When we started working on the app, we worked with a dedicated product owner and designer, both of whom were really invested in delivering a beautiful - but also technically resilient - product. Everyone had a clear role and different responsibilities, but we sat together, talked often, and made decisions as a group: product owners, designers and ourselves all bringing valuable different perspectives to the table.
Take the time to get things right
That close working relationship helped us prevent and deal with issues as they arose: there was a high level of trust across the team, and we were given the space and time to get things right and fix small issues before they grew. At Funding Circle, all teams are Agile. On the Mobile team, we used our weekly demos as opportunities to review our deliverables, revise our expectations, and take time to explore assumptions and refactor existing code where needed. We had broad timelines for the project as a whole, but we engaged frequently with the product team to review our expectations of scope - ultimately cutting some features from the initial release so that we could deliver something with which everyone felt comfortable.
Surface and tackle difficult issues together
At Funding Circle, we use pair-programming to transfer knowledge about different parts of the system, and as an opportunity for wider knowledge-sharing and coaching. On the Mobile team, we do this too: we spend roughly half of every day writing code together with another member of the team. Throughout the app development process, this approach helped us to spot complex issues early and find the right solutions - by combining the knowledge, experience, and different perspectives of the wider team.
Make small changes one by one
Looking back across the project, one thing we might have done differently is to rewrite and deliver changes in the existing app, rather than trying to deliver the whole rewritten app in one go. Having defined what we wanted the app to do, and how we wanted to make the changes (involving users in user testing, for example), we could have chosen a few small areas in the old app to tackle first, delivering refactors to our investors one at a time. That would have meant continuing to work with the old application, but would have allowed us to get quicker feedback from our users, as well as managing scope-creep more tightly: with smaller changes, it’s easier to see when additional features have added significant extra pressure.
What should you expect?
At the end of this investment of time, what can you achieve? Can you solve the problems with an existing codebase? Well, our investors are happy: app users frequently call our customer relations team to tell us how much they enjoy using our product. The app doesn’t crash on them anymore, either. We have between 99.8% and 100% crash-free users on any given day. They send us their feedback, too - much of which we can now respond to in a matter of days or weeks.
And as developers, we feel much more comfortable with our codebase now, which has been reduced to 52% of the original one. We have got tests covering most of the relevant flows in the app (from unit tests to UI functional tests) and we have a completely automated Continuous Integration and Continuous Delivery pipeline (thanks to CircleCI and Fastlane). Just to give you an example of how quickly we can deliver now, last week, we were able to react to a user’s suggestion with a new submission to the App Store within three hours.