End of Life of an App

How a Stripe API product we worked on for 2 years became obsolete instantaneously and without warning.

The backstory

At the end of 2012, a former business partner and I decided it was time to try the bootstrapping thing again. A few years earlier, we had launched and sold an (unsuccessful) app that dealt with invoicing and proposals. It didn’t end well, and we didn’t speak for years. Long story short, the sort of new Stripe platform provided a unique opportunity for us. Stripe didn’t have an iOS app, they didn’t have plans to build one and we were in the market to build something.

At the time, the Stripe API was still in it’s infancy. Only a few scattered endpoints, and not exactly robust. We were eager to make it work, so we built Paid. And after almost 7 months of development, we launched the app.

Loved by many

The great part about launching an app like this is that it was easy to fill a void. Stripe didn’t have an app, nor was their Dashboard responsive in any way. In the mobile first world, it was incredibly annoying to check on your transactions on your device. The need was huge and the product justified. Although we were charging for the original app ($7.99), we saw enough downloads to justify the development. We were pulling in around $1,000 per month in App Sales.

In the first few months, we were approached by two companies about an acquisition (neither were Stripe). One in the analytics/data space and another that was getting ready to launch their own service on top of Stripe. The latter was looking to buy our user list to target as customers — the app was just a bonus. Ultimately, we turned both down because we wanted to keep building.

# of sessions over time for V1

A checkered past

The launch wasn’t all perfect. Due to the simplicity of the Stripe API, we weren’t able to pull dashboard data in any type of efficient way. To aggregate a summary for a single day, we had to first download all of the transactions for every single user for every single day, and sum them up. There just (and still isn’t) a way around this. So many users were excited about the app, but the app couldn’t keep up with the data. Summaries were incorrect, and ultimately the V1 was tainted by bad data for most of the launch.

The solution in our minds was pretty obvious and had a clear path. We could either get Stripe to build out these aggregated summaries (since they own the data, it would have been easy for them to write the queries) or we could build a backend service to do it ourselves. Although we felt like we had significant weight in terms of Stripe users to justify this type of work, multiple attempts and requests with the Stripe team went unnoticed and we were backed into a corner.

Paid just couldn’t keep up with the way it was built.

A second attempt

Although V1 amassed 2,100+ users, we knew that to make the summary data more accurate, we had to make changes to the architecture of the app (a pretty good problem to have). Ultimately, we landed on writing our own service layer on top of Stripe to gather transaction data (based on webhooks) to create the summaries. This was the only way we could ensure the data was correct. This was after the release of iOS7, so we had to rewrite the app anyway.

The aim was to simplify everything — the UI, the interactions, the branding. We wanted Paid to get out of the way of business owners.

Free for all

We had also made the decision to go free with the app to gather up as many users as possible (read: to make our little app shop a more desirable acquisition target to Stripe). Not everything was free, as we chose to charge for the ability to manage multiple accounts. This undoubtedly was the largest feature requested over the span of 1.5 years.

Spike in downloads in September

Beta

Dozens of people helped beta test. We had requests from multiple employees at Stripe to be on the beta list to which we were thrilled to have help. Although admittedly, we didn’t receive any actionable feedback from them. Our thought was that they were more interested in a “look and see” what they’re building level rather than a “help them test” situation.

We do not believe Stripe wanted to “steal” or “sherlock” anything from our app.

Doing better with V2

We couldn’t have asked for a better reception to the second version.

User growth had been great (although at times inconsistent). For a side project, we were very happy with the amount of downloads. The data was looking good (albeit expensive at Heroku). Usage and engagement was great (and slowly growing).


The end of an era

Unfortunately for us, the team at Stripe created something incredible. Last week, we found out that around the time period when we were in beta with our V2, the Dashboard iOS app project kicked off at Stripe.

Stripe created something that two guys, with full time jobs and families couldn’t create as a hobby project.

It’s pretty easy to see where this graph is headed:

We’ll be taking Paid offline in the following weeks.

We don’t have a specific date planned for EOL, but it is imminent. It doesn’t make sense for us to continue to pay the Heroku bill for data you get for free via a sanctioned app.

V1 + V2 Stripe stats

Dashboard by Stripe

The great thing about the new Dashboard app is that they solved all the pain points we (and many services built on top of Stripe) outlined for them. Our users yearned for search, graphs and better/faster summary endpoints. Perhaps it was because Stripe was busy taking over the world (Twitter, Pinterest, Apple, etc) that they didn’t have the time (nor desire) to accommodate our requests. We’ll probably never know.

Reflection

Did the launch of Stripe’s Dashboard sting? Absolutely. Was it disappointing to have done so much work to have the recognition wiped out? Yep. Did we want to be acquired by Stripe? Yes. Did we reach out to them to work on our app full time, as employees of Stripe? Yes, although we never heard back. Did things go down the way we would have wanted? Nope. Did we feel cheated? Not really.

We can’t speak for the intentions of anyone but ourselves. We did everything we could for our users as well as everything we could to support the users of Stripe. We propped up a missing piece of their business for 2 full years and learned a lot about competing with similar apps, building scalable apps and nurturing a relationship over time.


Lessons Learned

  1. Building an app on top of an API is easy. There are tons of services that need better apps. Go build something.
  2. Being a 3rd party app is not always the best solution. You can be crushed at any time, without warning, no matter the working relationship. Gaining trust is also really hard.
  3. Customer support is time consuming. It’s much more exciting to move on.
  4. Making money is hard. We started off paid, but weren’t seeing the growth. We went free, and didn’t see the income.
  5. The relief stage of grief comes a lot faster than anticipated.
  6. The decision to split Paid and Payment was a good one. Payment will live on as it’s own app until it too gets replaced by an official app. Let’s hope Stripe doesn’t move into Square’s space.