The TestFlight App Strategy

Building MVPs quickly with Parse to validate ideas

Hi, I’m Zach — I’ve built my app business to about $4m in annual recurring revenue. Building a successful app business is really hard. That’s why I write a weekly newsletter about the things I’ve learned along the way. My goal is to help you grow your business and profit. If you want to learn more about the app business, I highly recommend subscribing.

My new app strategy for 2021 is going to be sprint-build a minimalistic app in 2-3 weeks using Parse backend and then launch on TestFlight to existing users from our other apps. If there's retention and other good signals, we’ll build it properly. Otherwise, we’ll scrap it and build something new. Repeat this process 10-12 times throughout the year and hopefully we find 1-2 home runs that generate $2m+ annual revenue.

This strategy resembles how Clubhouse was launched. v1 of their app was super basic. They launched on TestFlight and made it invite only. The design was good-enough and by no means anything special. The functionality was dead simple—you can enter a room and talk. They let users and their own analytics lead their product/feature decisions. To this day, the app is still very basic and their design doesn’t impress me. Nonetheless, it’s in the top charts without a single dollar of paid advertising. 

I’ve been trying to figure out how my company can absolutely blow up revenue growth. Perhaps the easiest way is to launch a product that some of our 250k+ users would be interested in. With that, I have lots of ideas and problems that I think are interesting in the social media tools space. So fuck it, we’re just going to start firing off ideas Clubhouse-style until we find something that sticks. 

The absolute last thing I want to do is spend 3-6 months prototyping, designing, and engineering an app that our user base doesn’t find helpful. I don’t have such a level of conviction in any of my ideas that would justify such a significant drain of resources. That’s led me to this new strategy. I have no idea if an app will work or not. I can have a theory, or a prediction, or confidence, but I will not know until it works. That’s why getting an MVP to market ASAP is the best way to test out ideas.

When I think about Hashtag Expert, my most successful app, there is essentially one feature I built in a week or two that is the core of the app which is the concept of using an algorithm to generate hashtags. Since then, I’ve just incrementally improved the app: a better design, more algorithms, a better algorithm, trending charts, etc. 


The first step is thinking of an idea that is informed by a problem. The idea will be a hypothesis to solve the problem. I’ll do my normal research (look at competitor apps, check revenue estimates, do keyword research, etc.). I’ll then distill the idea into the absolute simplest, most minimal version of it possible. The app should have one core feature.


For design, we want the app to be usable. Usability is crucial, looks aren’t. I will personally mock up ultra-ugly, sketch-style wireframes of the flow of the app.  I’ll tell the designer to prioritize getting designs done as fast as possible and not to worry about making everything super pretty. All of these test apps should have identical designs to optimize for recycling down the road. We want to lean on standard iOS elements as much as possible (i.e. default datepicker, tableviews, fonts, colors, etc.).


To code the app, we’re going to reuse whatever we can from existing apps. We already have some internal cocoapods for analytics/attribution tracking. For the backend, we’re going to use ParsePlatform. It’s a major waste of time to build out a scalable, legit restful API backend to test an idea. I was originally thinking of using Firebase but our new engineer convinced me Parse was better and I 100% agree. Here’s why:

  1. Scale - Parse can scale to a substantial amount of users because it’s simply hosted on an AWS EC2 Instance and uses MongoDB. We could easily run an app with 500k monthly active users on Parse + AWS EC2.

  1. Migration - if we decide to migrate off of Parse, we own the underlying MongoDB database and can simply build a new layer. This is super important to me because I’m used to the rigidity and horrible data portability of CloudKit which has screwed me over a lot.

  1. Extendability - Parse Platform is mounted onto a Node.js express server - that means any tools that can be used with Express also work here (i.e. API monitoring) - we can also build custom routes wherever we want or add custom validation to certain API requests. You get the benefits of running your own custom backend and the benefits of an out-of-the-box platform. 

I’ve tried both ends of the spectrum. For some of my apps, we’ve built from scratch an entire backend and it’s tedious and prone to bugs. On the other hand, we’ve built apps on CloudKit which provides nearly zero flexibility or data portability.

ParsePlatform works out of the box and has everything we could possibly need to validate an idea. The goal is getting to launch as quickly as possible. My engineer spinned up a working Parse Server on EC2 in under an hour. 

Inside the app, we’ll install robust, event-based analytics (Mixpanel) which will be used to evaluate the merit of the idea. We’ll also add push notifications and features that enable us to survey users. Whether through emails after they install the app or in-app forms, we’ll be collecting feedback as much as possible throughout the process.


We’ll launch to existing app users. We’ll send an email to the 200,000+ Hashtag Expert users and invite them to try the new app. I’ll tweet about it too and maybe send out an email blast. That should get enough users to validate the idea.


Post launch, I’ll be paying close attention to the metrics and try to answer a few questions:

  • Are people coming back to the app? Is there retention?

  • Are people engaging with the app? How long are sessions?

  • Are people utilizing the core feature of the app? 

  • What are people saying about the app in the survey data?

After we start collecting data, I’ll be able to make a decision about the future of the app. If I’m seeing good signals, we’ll continue iterating on the app until we get to a point where we’re comfortable launching it publicly. I’ll start drafting out ideas for monetizing it. We’ll make it available for Pre-Order immediately to start collecting downloads. If we’ve made it this far, we already know the app has legs so we’re not wasting time building an app that nobody wants.

If we see horrible data, we’ll throw out the app idea entirely. Worst case scenario we burned 2-3 weeks of time. That’s really not bad.

Macro Strategy

There are few things I hope to achieve with this strategy. 

I want to build a company culture where we become experts at building out apps quickly. Our first, second, and maybe third app might take a bit longer than normal, say 6-8 weeks. As we learn, we’ll build our processes, write more reusable code libraries, and have universal designs that’ll enable us to launch apps even quicker.

I’m hoping to find 1 or 2 home runs this year. I would define a homerun as getting an app to $2m+ revenue in the first year. I already have a very skilled marketing team in place that is managing $100k+ in ad spend a month on Hashtag Expert. If we see one of these TestFlight apps has legs and we build it out, we can then plug it into the existing marketing machine. Getting that up and running is trivial since we’re already advertising another app. The marketing team plus all the existing users on our other apps means we can scale very quickly.

Overall, I’m super excited!

Leave a comment