Learn from my $10,000 mistake


Fueled by the prospect of creating the next cool app, growing it to millions of users, and possibly getting acquired by a tech giant, I launched into designing and building a mobile app with relentless intent. Admittedly, I fell victim to the allure of mobile apps and the pursuit of becoming a tech entrepreneur. Along the way, many mistakes were made in designing, developing, and launching my iOS app, SubscriptMe (I no longer own the domain). SubscriptMe was an app for consumers to track monthly subscription services.

Don’t get me wrong, though. I believe those mistakes were worth much more in the long run than the actual cost to build the app. This is my (biased) examination of the process and breakdown of the learnings after $10,000 — and a lot of time.

Invalidating your product idea

When starting out, I used market research, surveys and customer development, hi-fi mockups and smoke screen tests to “size” the problem and to “validate” SubscriptMe before building it. In late 2014, I created a landing page (see below) and drove AdWords & Facebook traffic to the page to see if I could convert website visitors(we had a 10% conversion on a few hundred ad clicks).

Original SubscriptMe landing page created with LaunchRock

This, along with the market research I had conducted was convincing enough for me to consider building the iOS app. I proceeded to design and scope the app, find developers to build, and ultimately launch the app.

Ever hear the saying, “absence of evidence is not evidence of absence”?

The success of a smoke screen test (such as my landing page) and the market research did not necessarily validate the business — it just didn’t invalidate it.

Fundamentally, validating your Next Big Idea (NBI) can be deceiving if you design tests that set you up for success. The mindset of “validation” betrays emotion and logic as you look for any little nugget to justify building that app. In my case, I was dead set on building this app even before I started testing an MVP.

Instead, the focus should be on proving that the NBI might not have a viable business model at all. Invalidating your business ideas are just as — if not more — important as MVP validation.

How do you invalidate effectively? That’s the art.

Customer development may very well be the best first step. It’s important to conduct customer interviews without that validation mindset. You can very easily lead customer interviews to the answers you want to hear. Don’t try to control the customer conversation — let the customer naturally share his/her problems and let this lead you to the problem identification.

Also, demonstrating buyer intent is critical. Many MVPs, mine included, fail to measure a buyer’s willingness to pay for a product or service. It’s really easy to get email addresses if you know how to target the right people — getting them to pay is a whole different story.

Eagerness and excitement are powerful agents, especially when first starting off, but they can be blinding to your overall goal and best intentions.

Choosing the right technology

At the beginning, it may seem like this will have little impact on the outcome of your startup, but I think this topic often gets overlooked. Mobile is sexy, convenient, ubiquitous — whatever you want to call it. The fact is, it’s really freaking hard to make it with a mobile-first business (especially when targeting consumers). Mobile apps should be conduits into your business, but not the primary way in which you make money.

When we started development of SubscriptMe in late 2014, Facebook’s mobile back-end-as-a-service (BaaS), Parse, was growing in popularity. It was developer friendly, super easy to build on, and best of all, it was a pay-as-you-go model (which effectively meant it was free for us since our usage volume did not trip any payment lines). We are wholly dependent on Parse and now Parse is shutting down. Now we are faced with the decision to rebuild the back-end, shift to another BaaS provider like Firebase, or shut down the app.

A look at Parse’s user portal. Note the message at the top.

A downstream manifestation of the “choosing the right technology” problem has to do with the fact that we built a native iOS app. Changing our server-side code (i.e. switching off of Parse) will require rewiring the client-side and releasing a new version of the app if we choose to go this route.

We could have built a web application, an HTML5-based “hybrid” app, or another product to solve the “track subscriptions” problem, where we owned the entire infrastructure and experience. Building an iOS app requires a lengthy app store review process, and thus, making changes rather quickly is a big challenge.

Additionally, we utilized two technologies that were hard to maintain and ineffective at helping consumers actually find and track their subscriptions: app sniffing and email inbox scanning. App sniffing searches your phone’s index of apps — we used this to guess at which subscriptions you might pay for. We used Slice’s API to scan receipts from your inbox as another source of your paid subscriptions. Ultimately, using a 3rd party service like Plaid would have been more effective at finding relevant, recurring credit card charges.

How do you choose the right technology?

Think about your long-term goals and user behaviors. What is the primary way a customer would want to use your service, and does it make sense in the context of how you will make money.

Think about emerging technologies, too. When we built SubscriptMe, chat bots and contextual UIs were not really a thing yet. Now, these technologies are the basis for many startups you see all over TechCrunch and Product Hunt.

Building custom back-ends may be more expensive upfront, but it can prevent you from being pigeonholed in the future. Though there numerous enabling services and technologies, it is still relatively easy to get started when having to configure a server, set up continuous integration, and building authentication.

Design and user experience are differentiators

My tendency is to jump right into sketches and mockups. I have a designer’s mind and love to visualize how a product will look on paper. I created a “shitty first draft” of the app, linked screens together with InVision, and voila, a user experience was born (see below).

Here is a look at an initial prototype I used to gauge interest in SubscriptMe

It doesn’t take a design expert to realize that the prototype was lacking in a unified user experience. And, did this really make sense to be a standalone mobile app? Ultimately, the first production version of the app was a success in the press, but the design was poor. Because of the technology we chose to build the app (Swift, auto layouts) I ended up designing a few flows in the app that probably cost us somewhere between $2–3K in reworking the client-side code.

It was important to get the experience right immediately. One could argue that the medium we built on (iOS platform) was ill-advised in the first place. I spent countless hours redesigning the app in hopes that this might “save” the user experience and it’s shortcomings from being on mobile (another key failure was that most people still buy subscriptions on their desktop rather than on mobile devices).

How do you design a superior user experience?

User testing is critical. This may seem obvious, but remember my first point about idea validation? It’s very hard to see the limitations of your own designs without having other folks try to navigate the app. Constructive criticism and honest feedback are brutally important. Building an app in stealth mode means you’re doing it wrong. Potential customers should be providing feedback every step of the way through the design and development process.


After a year and a half of reflection, building and launching the mobile app was an incredibly valuable experience. The mistakes have taught me a lot. If you’re reading this, I hope it’s not too late (I like Drake, but I digress).

It’s OK to make mistakes, but take it from me and flip your mindset. Try incredibly hard to invalidate your Next Big Idea rather than to validate it. Choose the right technology by thinking about your user’s motivations and behaviors. Design an excellent user experience that is consistent with your tech choices and your user’s habits. Talk to your potential customers.

Keeping all this in mind, your Next Big Idea might be just that.

Use your company’s blog posts to opine on current industry topics, humanize your company, and show how your products and services can help people.

Originally posted on Medium on June 1, 2016. Updated March 15, 2020.

Leave a Reply