The heart of tech is coming to the heart of the Mediterranean. Join TNW in València this March 🇪🇸

This article was published on January 25, 2014

Reset: When should you rewrite your mobile app?

Reset: When should you rewrite your mobile app?
Nicholas Clark
Story by

Nicholas Clark

Nicholas Clark is the CTO of DoubleDutch, the company that creates social event apps for trade shows and conferences. Nicholas Clark is the CTO of DoubleDutch, the company that creates social event apps for trade shows and conferences.

Nicholas Clark is the CTO of DoubleDutch, the company that creates social event apps for trade shows and conferences.

In September of 2013, Apple released iOS 7 and hinted that legacy SDK support would soon be dropped. At DoubleDutch (where we make mobile applications for trade shows and conferences), this iOS 7 announcement provided an opportunity for us to reevaluate the state of our product.

Our software had evolved over the years as we refined our vision, but we still carried around expensive remnants (technical debt) of this evolution. We needed to determine whether or not now was the time to start over and completely rewrite our app, prioritizing our long-term execution over short-term gains.

Through this process, I learned about the phases of startups, the consequences of growth, and when to rethink your product from the ground up.

Stages of a startup

At the inception of a startup, not much exists beyond an idea. You spend the next few months hustling: learning the market, meeting with potential customers, and forming a vision.

As this vision begins to crystallize, you build what will become your minimally viable product and scramble to find your first customer. This process continues as you ideally land some customers, gather feedback, and continuously iterate. Your market – and the need that your product solves – comes into focus.

From a technology perspective, the early team may consist of only a few engineers that are severely strapped for time. A limited understanding of a market, coupled with a lack of resources and allocation, can lead to product and architectural decisions which feel rushed in hindsight but seem necessary to keep the lights on in the moment.

At this stage, customer requests come streaming in, and each customer represents such a large percentage of the business that you have little choice but to accommodate them.

phone line

Some of their requests may be in line with the product vision, while others may be necessary one-offs. Just beyond a “do whatever it takes” scenario, keeping your core customers happy while simultaneously progressing the product remains critical.

Through the course of this chapter, your customer base will grow quickly, as will the features and complexity of the product. With a greater market understanding, you begin to identify core competencies and realize the need to focus on the product as a platform.

The code may become too bulky to iterate as quickly as desired, and the support costs compete with time needed to innovate. The configurability, which had helped growth, quickly becomes a burden and reduces the cadence of releases. This complexity also slows ramp time of new hires, increases configuration errors, and introduces bugs.

However, by now you have grown the engineering team in both size and expertise, achieved product-market fit, and are ready to start scaling aggressively. With a clear goal, and a strong team ready to execute, it becomes time to remove your technical debt and prepare for hyper-growth.

The pros and cons of growth

Achieving product-market fit is an amazing feeling, but you must remain nimble enough to move quickly and remain innovative.

When considering how to combat growing technical debt once you’ve hit this fit, there are a couple obvious options: 1) Iteratively refactor and improve components of the product over time, or 2) Invest the effort in rewriting (some) entire pieces of the product.

The former extends the time required to support the technical debt, but allows for continual improvement without a large upfront cost. A rewrite involves a huge upfront cost and a higher risk of regression, but also allows for an architecture designed for the future objectives of the product, rather than for its legacy needs.

When evaluating our codebase, a few indicators stood out and influenced our decision to rewrite a large portion of our code:

  • Core pieces of the product’s ideal roadmap required large architectural changes to achieve
  • The technical debt of the product slowed development speed and wore on the engineers
  • A growing number of features took away from the core experience of the product
  • An impending event (iOS 7) required some re-architecture at a minimum
  • The engineering team had a strong understanding of the product and vision

If you are in a similar situation, where an impending deadline requires a large investment of time and your product could greatly benefit from critical changes, then a rewrite may be the right course of action.

Weighing the risks

That said, a rewrite shouldn’t be an obvious decision. Dedicating an entire engineering team to rebuilding something that has already amassed a large customer base will stall any iteration until the rewrite is completed, and will introduce a much higher risk of regression.

A rewrite bets on long-term priorities: increased speed of iteration, a focus on a refined end-user experience, and quicker ramp up time for new engineers.

For us, a rewrite meant that we had to divert the majority of our engineering team’s attention for four months, since we elected to improve our APIs and Android application along with iOS. An iOS 7 compatibility update, with no architectural improvements, would have taken a couple of engineers less than two months.

It was a risky decision – the event app space had become increasingly competitive and our current app was selling very well. With a company-wide goal to grow as fast as possible, the product rewrite seemed at odds with grabbing market share. We weighed the risks of a competitor catching or surpassing us, against our ability to innovate quickly and effectively in the future.

Taking the leap

Considering options like these, the most important question to ask is which risk is greater: The risk of slowing down on new feature development for several months or the risk of a competitor being able to iterate quicker.

For us, we believe in our ability to execute, and are determined to be the industry leaders. With that in mind, our desire to innovate outweighed the risk of a competitor overtaking us in the short-term.

When we originally wrote our app, we had a less mature understanding of the market, and were learning how to build the product as we went along. With hindsight and a strong foothold in the industry to guide us, we elected to learn from our past in order to prepare for our future.

It’s too soon to know whether or not we made the right decision, but the speed, performance and polish of the end result give us plenty of reasons to be optimistic.