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.
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.
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.
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.
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.
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.
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.
...
[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.
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.
