“If people pay, that’s a strong signal you’ve built something valuable” — Kenneth Schlenker, Opal

Building an app business is hard. There are so many variables to think about that it’s easy to get overwhelmed, focus on the wrong things, and spend valuable time, energy, and resources on efforts that won’t lead to results.

Kenneth Schlenker knows all about these potential pitfalls and how best to avoid them. Kenneth is the founder and CEO of Opal, a screen time management app that has risen to #81 in the Productivity category on the App Store and has a 4.7-star rating from over 13,000 reviews. With just seven people on the team, Opal has hit $5M ARR. So how did they do it? They followed a slightly unconventional playbook that helped them stay focused on finding their product-market fit and moving the needle.

Measuring a single metric

Opal invested in paid acquisition early and focused on 8-day ROAS as a key indicator of whether or not they were growing. Too often, app businesses try to measure everything and get bogged down in the details. It’s much more effective to choose a single metric to measure and continually iterate to ensure you’re moving in the right direction.

Monetizing early

A lot of apps (like Duolingo, for example) start out free and then add subscriptions later after they’ve captured a large user base. Opal did the opposite – they launched with a fairly expensive annual subscription and are now pivoting to a freemium model to extend their offering to new cohorts of users like college students. Both of these approaches are valid, but Opal found that by adding a paywall early, they were able to validate that they were building something that people were willing to pay for. “It’s been a really interesting way to essentially use subscription as a discovery engine, as a product-market fit engine, just focusing on this one metric: day-8 return on ad spend,” Kenneth said.

Launching on iOS only

Another mistake lots of app businesses make is trying to launch on every platform right away. But this is resource-intensive and generally won’t lead to 2X revenue. Although your long-term goal may be to develop iOS, Android, and web versions of your app, especially in the early stages, it’s significantly easier to test your product-market fit and iterate on your app in a single platform. As Kenneth points out, “it’s easier in that discovery phase to do one platform… when you have two, you’re kind of stuck. I’ve seen a lot of horror stories from other startups that actually ended up launching too soon, and when you ask them, ‘what’s your greatest regret?’ they’ll say, ‘We went on Android too soon’ or ‘We went on desktop or Chrome too soon.’”

Key lessons from 121 A/B tests

Kenneth and his team have run a lot of A/B tests, so they know a thing or two about what does and doesn’t work. Here are a few key insights from their testing:

• Show your paywall early
• Onboard users into a scheduled session
• Offer tiered referral rewards
• The Blinkist paywall is hard to beat (if it isn’t broken, don’t fix it?)
• Don’t give users too much choice in onboarding
• The best re-engagement strategy is usually offering a discount

One last thing Kenneth recommends: maybe don’t run 121 A/B tests? You probably don’t need that many.

Listen to the episode: audio / video