Re-writing from scratch

Generally speaking, you should never rewrite from scratch. We recently discovered an exception: making fundamental changes to the UI of a (simple) web application. Counter-intuitively, starting from scratch made us much more iterative.

Background

The old GoCardless interface had been designed to make it easy to set up fixed payments. "PayLinks" were perfect for this - a single link with all the payment information embedded. Clicking one and completing our payment pages would set up a fixed payment plan to a merchant. Here's how the interface looked:

What "PayLinks" weren't good for was setting up and managing variable Direct Debits, against which ad-hoc future payments could be taken. These were quickly becoming our unique selling point to merchants.

Incorporating variable Direct Debits into our old interface required big changes in our UI. Not only were set up links required (as before), we needed functionality to manage customers once they were set up. No one was clear how to add this without adding significant complexity to the existing interface. Since simplicity is GoCardless's headline benefit that wasn't going to fly.

Our solution was to start from scratch in a new application. We built a new interface and then switched customers over. Here's what we learnt:

Starting from scratch let us iterate

Our old dashboards were at a local maximum, making it hard to iterate. Introducing elements of a variable Direct Debit interface would have added complexity, with no benefit until the whole new interface was ready.

For a fundamental change in UI that lack of iteration wasn't acceptable. Starting from scratch with an early beta let us to collect feedback on the new interface immediately. Our speed of iteration was also increased as we didn't have to worry about breaking an existing interface.

Starting from scratch let us launch faster

We launched our completely redesigned interface months before we tackled most of the harder problems in it. Initially launched for new customers only, in its first month the new interface added 10% to our revenue. 3 months in it accounts for 50%.

By building the new interface from scratch as a separate application, we were able to defer hard problems like migrating existing users over until after launch. Whilst we work on that migration the new interface is already having a positive effect on revenue.

Those tack-ons were there for a reason

As we rolled out our new interface to our older users, we heard requests for old features. Most were already on our roadmap, but there were others we'd missed. Typically, they were the small "fixes" that felt tacked on, but some users found essential.

After 3 months of iterations, for example, we've ended up with a top-level nav that looks spookily similar to before we started. Payments, customers, and payouts are all there, as is "Plans", which is very similar to "PayLinks":

We'd do it again

The cost of reimplementing existing features is obvious. Measuring the benefit of a rewrite is much harder. In our case, we've got no doubt that the benefits of an iterative approach outweighed the cost because it helped us escape a local maximum.

Adding an interface for variable Direct Debit was on our roadmap for 12 months, despite consistent demand from our users. 10 months of that delay were due to uncertainty around how to fit it into our existing product. That's a long time for any startup to be building the wrong things. Starting from scratch fixed that.