why make the app paid-only?
what’s happening?
In our newest update (1.2.109) we are premium-gating the mobile app for Tapped. This is a radical decision made that should ultimately improve the overall experience of both the website and mobile app, speed up our development of features and bug fixes, and get the performers on our app more bookings.
what does the current flow look like?
To know how this is going to change things for our team, I’ll brief describe how we build features on Tapped currently.
- listen to what users want
Our team messages a lot of users. User feedback is the primary way we prioritize features whether it be via DMs, the user feedback buttons all over the app, emails from users, app reviews on the App Store, or even social media DMs, etc. Other than direct feedback, we also gather indirect feedback from analytics from our analytics provider, PostHog. When we think we've got a good grasp on what to build next then we usually create mock ups of the feature in Figma so the team’s on the same page.
- build the feature into the webapp
Now we have to build it! For those who care, our web tech stack is Nextjs+Shadcn+Vercel for the frontend, Firebase for the backend+database, GetStream for DMs, PostHog for analytics, and Stripe for payments. We stand on the shoulders of giants to allow us to pump out features and fixes at an alarming rate on web. If something needs to be fixed, we can have something out in literally 30 seconds.
- do that again on mobile
After web, we next have to rebuilt the functionality into the mobile app. We can usually do them at the same time if it’s a backend-heavy feature but it still generally doubles the development time for a feature. Often we have to change the feature a bit to get around Apple’s abusive App Store requirements for example: Payments use their proprietary payment processor instead of Stripe which we link together using a service called RevenueCat or UI design is done using Material (Google) or Cupertino (Apple) themes instead of Shadcn because it feels more native and has much better support on mobile. Unlike on web, it’s really tough for us to test and profile mobile apps because the tooling is tough to use and stupid. The biggest difference though is is rather than 30 seconds to release updates and fixes, it takes several days to get updates out because Apple has to approve every update we make.
- measure success
Every feature is an opportunity to learn what works and what doesn’t. Our “north star metric” is “does this get a performer more bookings”. If the answer is “yes” we look into how to make it better and if the answer is “no” then we ask ourselves “why” or simply remove the feature.
how do we improve?
Each step in this process could be improved but obviously the building twice thing is stupid. It doubles the development time and extends the “build → measure → learn” loop we’ve got going for us. It’s also a very easy way for us to introduce tons of bugs into the codebase. So what do we get rid of: web or mobile? Users heavily prefer the mobile app but the mobile app has a lot of downsides that prevent us from iterating properly
As is apparent, web is great for us to be able to move quickly and effectively build the best product for our users. The cons of mobile are simply too high for us to simply treat it as an equal. Another thing to keep in mind is, although Tapped is open source and has had a few developers help our, the vast majority of contributions come from a single person…
what does making it paid get us?
But the fact that users prefer mobile app is a powerful motivator. We’re not just going to get rid of something that users genuinely like and are willing to pay for. So the decision we made was to focus feature development on the webapp and keep mobile as a perk for premium users. If you want the mobile app then as a premium user, it’s all yours. If you’re just curious to what Tapped is and exploring, then the webapp is a way better starting place for you.
By making this transition, a few things are going to get better.
- better mobile experience
The focus on mobile will be stability, premium experience, and an overall incredible app. The feedback we get from mobile users is higher quality (paying users always give better feedback than free users), will be made a higher priority, and bug related problems will be fixed ASAP rather than added to some never ending list.
example feedback from a free user (they never emailed our support)
example feedback from paying users
- faster feature development
The webapp will, from this moment forward, be our main sandbox for testing new features and experimenting on what moves the needle forward. The “build → measure → learn” loop is going to be significantly shorter and we intend on publishing our release timeline as well as an updated roadmap to look forward to what’s coming.
