Shipping Clubhouse on Android in ten weeks
blog.clubhouse.com
blog.clubhouse.com
It's amazing to see how quickly a production-grade app can be produced by a team that arrives with the knowledge and experience for connecting the right frameworks and apps together. However, my experience matches the author's in that the hardest work often isn't the technical part:
> And like most engineering projects, the hardest part isn’t necessarily in the technical work! What I found most challenging was context switching into the many different hats I’ve needed to wear: from interviewing and onboarding other engineers to grow the team — talk about building the rocket ship while flying it — to communicating progress and blockers as we went along, and to adjusting to getting to know my new coworkers in a remote world.
It's relatively easy for developers to sit down and write greenfield apps in isolation. It's much harder to sit down and integrate with an existing platform and launch directly into a torrent of users with high expectations, all while navigating the requirements of a rapidly growing business.
As for timing: I'm sure the Clubhouse founders would have preferred to have an Android app ready to go during their initial popularity spike, but I don't think the lack of Android app is what caused their popularity to decline over time. They obviously made the right choice by launching what they could (an iOS app) as quickly as possible to seize the moment. Even though the popularity has declined, they now have a large war chest to figure out where to go next.
Probably HN is the only place I've actually felt (1) while everything else falls into (2) after just a day or two.
My whole (mostly German) LinkedIn bubble was totally hyped for around six weeks.
Since then: Nothing. It's dead, nobody seems to use it anymore.
The only thing the company ever had was (fake, forced, paid) exclusivity. Once that went away people stopped caring (except those that were/are paid to be there, of course).
On the contrary, it was a beyond stupid to launch only on iPhone. I'm not sure if it was elitism or merely being poor at arithmetic, but it made no sense whatsoever.
And when you do break things, it’s relatively easy (especially on iPhone where most users upgrade apps quickly) to fix the client, wait for the next release, then remove the unwanted server feature.
Once you have two or more client implementations, you have to keep track of a lot more things, your QA checklist grows, and you therefore need to move more carefully for server upgrades.
In my country, influencers who had iPhones picked it up, and then promptly dropped it because most of their followers couldn't come to the party.
Only targeting the US is folly for a social media app. And even there, iOS has only 60% of the market.
Also, other rich countries, like say some north/west European ones, have a large (~50% or more) share of iPhone users as well.
If you need to go to market quickly, it makes sense to start with the trendy people with money, then you can go for the long tail of Android users.
Edit: Clubhouse isn’t an app where it matters whether every single one of your friends and family is on it for it to be useful/entertaining to you. And if you become established in the most desirable segments of some major economies first, you have a good foundation for going after the rest of the world later. There’s no need to try to cater to every single potential user on Earth from the get-go.
No, like any startup they needed to launch an MVP and iterate. Waiting until everything is available on every platform only makes sense if you have the time and resources, which they didn't. They were a small team with limited resources.
Clubhouse wasn’t explosively popular when it launched. The success came a few months later, at which point they had more people seeking invites than they wanted to allow on to the platform. Focusing on getting something minimal out the door and scaling it up is the right choice.
If you’re going to pick one platform to launch an MVP, iOS is almost always the right choice. Tech enthusiasts and early adopters skew toward iOS by a small margin and iOS is a more predictable platform to develop for because you can count on most of your user base being on the current iOS version. Android is a development minefield by comparison, especially when it comes to audio and video.
I agree, but they didn't. There was no MVP for Android.
> Waiting until everything is available on every platform
Not everything, just an MVP. Wait until you have an MVP on the biggest platform first, and then launch.
> Focusing on getting something minimal out the door and scaling it up is the right choice.
Yup, an MVP on Android and iOS would have been perfect.
> If you’re going to pick one platform to launch an MVP, iOS is almost always the right choice.... Tech enthusiasts and early adopters skew toward ....
Again, this is true for most cases, but not an app like Clubhouse. In most of the world the influencers jumped on it immediately but dropped it like a hot potato when they realised none of the people they wanted to influence could show up to worship them.
Releasing on both platforms is now the expected choice.
I don't think Clubhouse can get away from the 2010-era excuses, especially when they had a lot of VC backing and plenty of cash in less than a year. They were more than 6 months late and the competitors already copied them entirely. No waiting for invites.
They might have launched much quicker with both iOS and Android had they chose a cross-platform toolkit like React Native or Flutter.
Even the Discord app uses RN and they copied their main features much quicker than Clubhouse could write the Android app and it has worked great for Discord.
By the time Clubhouse finished the Android app and 2 months later removed the invite system. It was beyond too late.
If you’re building an early stage consumer startup in the US, you should launch first on iOS period. Use that starting point to iterate rapidly to figure out product-market fit and then launch Android.
There is a reason you see the best consumer companies take this route and it’s not because they’re poor at arithmetic.
If you always default to launching on iOS, don't be surprised if user adoption is further limited when you eventually get around to launching on Android since by then, there would be competing products or you'll have difficulty changing the perception of "this company thinks I'm a 2nd class citizen, why would I bother?"
(Snap faced some of this for a while though I'm not sure what their distribution metrics look like now)
There is also a critical window when launching on multiple platforms. If you wait too long, the brand's "xyz OS only" will stick and opens the door for your competitor to say "We're like that other app but we actually work and sync across all your devices".
Apps are cancer. Apple is the company responsible for this mess.
None of the points you raise are real issues. Android is in-fact a second-class citizen and should be prioritized as such.
Again, there is a reason you see consumer companies adopt an iOS first strategy. Experienced founders can tell you why.
By the way, Snap is a $100B+ company - that’s not a great example to make your point. If your product works, people will come - even the ones that claim they won’t. Cross platform competition is not a real concern.
Not really if you care about number of users:
We are specifically talking about launching an early stage consumer startup pre product-market-fit in the US.
Please consider that they are a small team, have gone under what can only be considered a monumental explosive growth, and given circumstances, shipping an app from scratch in less than 2.5months can be considered pretty good.
Also, they haven't added any features to the iOS app, and their voice quality in the height of it was really lacking (low qual. and lots of hickups), and there were room limitations, etc....
Anyway, it is remarkable what they achieved, as most of us (or our projects) will never get to that growth curve hype they did get, and hats up to them, and yet it is disappointing at the same time as it fizzled out.
Feels like Friendster from 2003. Explosive growth for a while, but struggled to scale with features and usage load until it fell away.
Amazon spends almost a billion a month on marketing. Procter & Gamble is almost the same. L'oreal is around $850 million a month in marketing spend. I'm sure some of their campaigns run into the tens of millions easily. In fact, I think it would be pretty difficult to spend a billion dollars on marketing every thirty days without at least one individual campaign spending more than $10 million.
But the snark that I have, is less directed at the clubhouse team, than it is against the cult-like users of clubhouse that I would run into or argue with, X number of months ago, that were clearly taking an app way too seriously.
If you live by the Hype, then you will die by it.
Maybe clubhouse will turn into something interesting eventually.
But it is clear, that all of those influencers and users, who were making out clubhouse to be some world changing app, that will revolutionize social dynamics, were wrong.
Avoiding VCs and accounts in their orbit helped as well.
...
[1] https://vk.com/wall-55882680_74 (in Russian)
I had FOMO for all of a week, and now I don't care. There is not room in the current ecosystem for another meeting app. I don't see a long term future for this app.
Would it be fair to say they could have gotten to market quicker had they went with RN?
Would love someone from the team to elaborate on this as Agora also has RN SDK's as well as Firebase.
1) the CH iOS app itself has a long history of powering other prototypes / small communities before CH existed — so I think the early engineers were leveraging what they had already, vs starting out from zero. (I think this is why they were able to find fit with CH - ability to move fast and try different things.)
2) I built an app with RN at a previous company and it was a reasonable experience, but custom UI / transitions / etc was pretty much out the window. I don't think it's an obvious choice by any means to go with RN, especially for a media-heavy app. Also, expanding that particular RN app I had built to Android was no easy task — the UI mostly "just worked" when we built the Android container, but many of our third party libraries didn't work at all on Android, and managing app navigation was a huge hassle between the two platforms. We ended up shelving the android effort altogether and shut the whole project down a bit later. :)
I haven't looked at React Native, but in Xamarin all the easy stuff (basic layouts, logins etc) were no easier than writing native Android code, and the hard stuff was a lot harder due to having to integrate the native code.
Which is why I always advocate for mobile Web (plenty of CRUD apps are doable as such), native views + C++, native + server driven UI/business logic.
Mobile SDKs are already complex on their own, adding an additional development stack on top just makes everything worse, and when things go wrong one needs to be skillful enough to dig deep down anyway.
If those JNI bindings are a pain to write, having to debug the additional layers that React Native, Xamarin, Flutter, whatever put on top isn't much fun either.
As an extinct user, the experience increasingly diminished the more "creators" were enabled / whatever started becoming of the "creator-first" mantra. It last felt like i was on a TV guide scanning through a bunch of paid programming, c-class doctor phils, and had lost the connections I made / ability to do the whole collective learning that felt really powerful at one point.
Clubhouse felt like "something else" for a bit, and then suddenly it didn't. I stopped using the app right around when android was released. I think Android users missed out.
Now I want to know how Superhuman has gotten away with not having an Android app for so long, and what on earth they could be doing given they say they have been "working on it" for years and over $100 million in VC funding.
The users do not care if it is native or not. As long as it exists on their platform of choice, they will use it.
The fact that it was not on Android in the first place, then being copied by the existing competitors and lockdowns lifting is the reason why the hype fizzled quickly and by the time they finished the Android app, it was already too late.
I have told folks, on occasion, that have approached me to do apps (I write native Apple apps, in Swift), that they are probably better off, looking at doing hybrid apps.
One advantage of starting off with a single-platform native app, is that it can act as a "design spec and MVP" for the second platform. I suspect the Android app will be a lot better that the iOS app (which I wasn't really thrilled by).
They probably only had a native iOS app developer, on hand to do the work, when things got started, and it isn't actually a bad business decision, to start with Apple.
The app I'm developing now, is iOS-native, and we decided to go with Apple, because that was the talent pool on hand (Yours, Troolie), and a significant number of folks out there, have the ability to run Apple iOS apps.
Also, in my opinion, you are best off starting with Apple, because the platform is more restricted than Android, so you aren't as likely to develop capabilities on one platform, that can't be implemented on the other.
Yeah. Ten weeks for an Android app to meet feature parity with an iOS app that had over a year of development with millions of users is pretty astonishing.
There are many edge cases that come up when something you develop is used by millions of people and they typically get handled as they come up during your growth period. For example, when I worked at FreshBooks over a decade ago we had to support invoicing with currency conversion support for expenses. Some users wanted to input currency costs in the original currency and have us automatically convert it to their native currency, others at the currency conversion they were billed by their native currency via their bank's conversion rate. Still others wanted support for one or the other, but with different reporting flows for either. The fine detail of how to handle different circumstances isn't apparent until you've actually had to deal with it for your customers as they use your application.
So to go from app on platform X to app on platform Y with near feature parity is a lot more work than just slapping something together.
Is every error response handled correctly? Are the user safeguards implemented properly? Does it work across different kinds of devices? Are the third party APIs for payments, etc, wired in correctly? Why does this third party service fail for this new platform at 3% when the existing platform fails at 0.01%? Is every error case handled for every third party service? Is the exception logging wired in properly? Does the backend record misuse correctly despite the fact that the platforms provide different information on request? Does the UI respect the native controls where necessary? During the time from project start to the time when the project finished did we make sure to include all of the features added to the already supported platform?
Anyway, you get the idea. Software MVPs are relatively easy, but quickly launching into an already developed user base takes a great degree of skill, and honestly one of the things I really enjoy about working here is the people and I've worked in tech for a while.
They even haven't shipped full onboarding and contract import flow at all in the first release.