How we rewrote the Kicksend web app in one month

Startups have a phase where the first generation of the product has to make way for the second. In our case, we set out to create

  • a wonderful experience for our users
  • a faster, leaner front end code base
  • a great foundation to build out new features faster

And, those goals meant it was also time to rewrite part of our Kicksend stack.

Rewrites are strangely attractive. Developers love to work on a sparkling clean code base. But in reality, there’s much more to a rewrite beneath the surface. Like all those implementation subtitles and edge cases you took for granted.

Before jumping into a rewrite, start with the business and product considerations, because if a rewrite is the best path then with the right planning and approach, you’ll avoid a lot of pain.

Here’s what worked for us at Kicksend.

Be very clear of your goals

Rewrites can quickly balloon out of control. There will always be the tendency to throw in new features. So it’s important to keep the scope of the rewrite focused. Scope out a minimum viable rewrite – a great place to start would be hitting feature parity with the original version.

We set out to rewrite only the upper levels of our stack, and not the entire application (there was no reason to). In terms of changes, that meant we had three goals:

  1. a migration to a new database schema
  2. a refactored, new RESTful set of APIs
  3. a complete rework of the web application

With those goals in mind, we made sure to hammer out the scope and implementation of each item. We whiteboarded the schema migration, the APIs, and iterated on the new web application’s user-facing design before we wrote a line of code. After which, we split these items up into Pivotal Tracker stories.

From then on, we made it a point not to introduce any features that weren’t directly related to the implementation or didn’t fall in line with our goals, which worked well to curb feature creep.


It’s a rewrite. Take the opportunity to simplify.

Each feature and technical decision that made it into our rewrite had to meet the following criteria:

  • simplified our technical implementation
  • improved user experience
  • boosted productivity

1) Cut out Features – Since we measure everything, deciding what to leave out of the rewrite was a straightforward, data-driven decision.

2) Optimized UX – An example of a feature that we did rewrite is “Lists.” In Kicksend, lists are great way to easily send files to private groups of people. We felt that this was a core experience of Kicksend, and we had to nail the user experience. With the rewrite we introduced more intuitive ways for our user to manage their lists and achieved simplification.


 3) Swap to Coffeescript – Using Coffeescript made this development simpler and fun, which in turn boosted our productivity. For the curious, the rest of our frontend stack consists of Backbone.js with Handlebars.

On balance, the scope of our rewrite actually turned out to be smaller than the original version.

Get it on production. Now.

Don’t do a waterfall-style “big bang” release. Don’t coop up your rewrite on a staging box, only to be deployed to production on release day. The quicker you can deploy an iteration of your rewrite to production, the easier your life will be.

We spent the first two weeks preparing our code base to accomodate the rewrite on production. That meant a whole bunch of chores like retrofitting our current APIs to write to the new schema, changing up the web application to use the new set of APIs, and migrating over to Rails’ asset pipeline. After all that, we were running our rewrite live in production, in parallel to the original version.


  1. We continuously deployed (our usual cadence)
  2. We battle-tested our rewrite in production for a month and a half
  3. “Launching” just meant flipping a switch

Rewrites are tempting, but can also be deceptively complex. Don’t rush into one. Have a well thought out plan. It worked for us; we launched smoothly and right on schedule.

So check out our shiny new web app, or grab our mobile and desktop apps.

Catch us on Twitter at @kicksend and @derrickko. And join in the discussion on Hacker News.

PS. Sounds interesting? We’re hiring.


  • Reply May 17, 2012

    Paul Stamatiou

    Would love to hear more about the structure of your Backbone app. We run a similar stack at Picplum – all coffeescript, backbone, require.js for AMD’d everything, and we try to reuse views as much as possible (pass in different templates if necessary, but never a different view).

    • May 17, 2012


      I’d also love to hear more about usage of backbone with require.js.

      Paul – knowing you use that in Picplum, I was actually going to reach out to you to do a write-up on how it is implemented in Picplum. I’ve been using backbone, and requires for about a a couple months now for an internal tool at Call-Em-All and enjoy it, however, there are times I feel like there could be a better way (read: efficient) than how I am using it.

    • May 17, 2012

      Paul Stamatiou

      Hey Seth,

      It has definitely been on my to-do list! Our new require.js refactor isn’t actually live yet but once I finish it up and push it I hope to write about it.


  • Reply May 17, 2012

    Michael Shafrir

    Enjoyed the writeup – great looking site. Out of curiosity, how did you settle on Handlebars as your templating library? Do you share any templates between the server and client?

Leave a Reply

Leave a Reply