What does DelightRoom think?
1
How have you been lately?
When I catch up with acquaintances these days, our usual first words to each other are "How are things?"
Since most of us work at startups and are feeling the full force of the "startup winter," we check in on each other's well-being even more often.
In particular, we often talk about the efforts going into surviving these tough times, like restructuring due to worsening financials, hiring freezes, and cutting operational costs.
Among these topics, whenever I go to developer meetups (for tech exchange and consulting), the conversation inevitably turns to various productivity hacks because there's so much work to be done with such tight resources. Even if the startup world is in a winter, the value we need to deliver to users doesn't shrink, which naturally deepens our concerns.
Whenever that happens, the topic of cross-platform development always comes up.
From my experience, there's been a noticeable movement in Korea toward considering React Native as a primary tech stack since around 2018.
(Since then, as Google's Flutter also gained traction, the heat around cross-platform development has really been rising in the developer community.)
How about cross-platform?
When resources are tight, cross-platform development is often mentioned as the easiest solution to turn to. Ultimately, cross-platform is supposed to be one of the ways to solve productivity issues.
Oh, before diving deeper into cross-platform, to give a brief introduction, you can think of it as creating both iOS and Android apps with a single development effort.
(Usually, when building an app, you have to develop it twice—once for iOS and once for Android. Think of it as reducing that down to a single development process.)
The clear expectation for cross-platform lies in the "one source multi use" concept. Driven by this, people end up building products expecting a 2x boost in productivity.
But whenever I meet up with people, we frequently end up asking, "Is this really a 2x productivity boost?"
That's because it's hard to hear about easy success stories of services built with the major cross-platform tools (React Native, Flutter). The well-known examples (Facebook, Instagram, Grab, Discord) are companies that already have over 100 engineers,
so for startups where the entire company size is under 100 people, it's hard to really relate to those cases.
So, I want to break down the pros and cons one by one to see if productivity improvements are actually possible with cross-platform.
But there's a premise here. Among business problems, I think there are those that can be solved well with cross-platform and those that cannot.
Broadly speaking, we can first divide things into what is 'implementable' and 'unimplementable' with cross-platform.
And among what is implementable with cross-platform, I thought it could be further divided into 'high' and 'low' difficulty.
If we visualize the premise above, it looks like this.
Pros
Code that can be reused across multiple platforms
Faster development speed
Lower maintenance costs involved
Faster time-to-market (since it launches on iOS and Android at once)
Cons
Requires additional development resources for features that need hardware support (sometimes not supported out of the box by cross-platform, and even if it is, there can be performance issues during implementation)
Performance is slower than typical native products
Cannot consistently follow the design principles guided by each platform (it's hard to create consistent UX while adhering to both the Human Interface Guidelines and Material Design)
The pros and cons listed above are pretty generic, so I don't think they provide enough grounds for actual decision-making. And sometimes I wonder if the development speed and maintenance costs are truly lower.
First of all, what startups need to determine before choosing cross-platform is:
Who are the specific users we are targeting right now? (Persona)
What is the user value we are currently trying to provide? (User value)
What are the core features essential to that user value? (Core features)
Once you define the user problems based on the above and complete enough research showing that cross-platform is a viable way to deliver fast customer satisfaction, then I think you can make that decision.
When doing sufficient research, I believe these criteria can be considered:
Do the core features heavily require device support?
What is the minimum expected performance between core features?
If we develop using cross-platform, is the workflow sufficiently efficient?
When providing the core features, can the UX follow the default design principles of both platforms?
….
Ultimately, I think you just need to use it according to the situation your company is facing.
If you search around, you'll find that there actually aren't many detailed case studies sharing lessons or experiences regarding cross-platform usage.
One prime example is Airbnb, who used React Native more intensely than anyone and shared their lessons and struggles in detail, which was quite helpful. (The content is super solid and a really fun read. Although, they did end up dropping React Native in 2018 and declaring a return to native.)
I'm leaving the links here because they're great references.
2) React Native as a Technology
3) Building a Cross-Platform Mobile Team
5) What's Next for Mobile at Airbnb
Now, I'd like to share how DelightRoom views cross-platform.
But before that, let's talk about our product development philosophy.
Do things that don't scale
At the base of DelightRoom's product development philosophy lies the idea to "do things that don't scale."
(Our CEO, Jay, is a massive fan of Paul Graham, the creator of YC, and loves his essays. He even translated "Do Things that Don't Scale" himself.)
What left the biggest impression on me when I read Paul Graham's essay was that,
for the customer's happiness, things like automation, scale, engineering, or aesthetic excellence don't matter (especially for early users),
and that you have to quickly figure out what you can do right now to satisfy the customer's needs and just do it. (Even if it's inefficient...)
At DelightRoom, where we have a product development culture obsessed with our customers, "Do things that don't scale" has really resonated with our members.
So, when we do things that don't scale, we expect a few things:
We can grasp the customer's problem much more deeply and in detail
Based on that, we can deliver even greater customer satisfaction
By doing so, we can actually find a more scalable solution down the line
We work while holding onto this belief.
You're probably wondering, "What exactly are 'things that don't scale'?"
Let me give you a few specific examples.
✅ Stripe Example
Problem: Wanting to know the issues users face while using Stripe after installation
Scalable way: Users go to the website, install it themselves, and report usability issues online
Unscalable way: When someone says they'll try using Stripe, immediately saying "Give me your computer," installing the service for them right then and there, and observing them use it
✅ Airbnb Example
Problem: Wanting to get feedback on the needs and desires of Airbnb users (hosts renting out their rooms)
Scalable way: Receiving feedback online regarding the usage needs of customers from any country
Unscalable way: Flying straight to New York to specifically listen to the needs and desires of New York customers
✅ DelightRoom Example
Problem: When the alarm rings, we want to prevent the issue of users turning off their phones and missing out on having to wake up
Scalable way: Preventing the method of turning off the phone in the exact same way across both platforms
Unscalable way:
Android users: Using system features so that when the power-off screen is triggered, the Alarmy screen keeps popping up over it, ultimately interfering so they can't turn off the power
iOS users: Since iOS doesn't allow interfering with the power-off screen, we detect the power turning off, and when they turn the phone back on, we give them a notification bomb. We remind them with notifications even at that point. They might miss the alarm once, but the next time they try to turn off the phone, the burden of the notification bomb makes them hesitate to carelessly turn it off.
(These features gave users considerable satisfaction at the time, but as the OS has been updated and system permissions have become stricter, these features have since been removed. However, we are now providing features that resolve user needs in different ways.)
Looking at these examples, "scalable ways" seem like highly ideal solutions, but when actually faced with a problem, it's often difficult to solve the user's issue right away.
Even in DelightRoom's case, if we had been using cross-platform with scalability in mind, I think building that existing solution would have been almost impossible.
We probably wouldn't have been able to persistently dig into that issue and would have just brushed it off thinking, "Well, there's nothing we can do if the user turns off their phone."
Ultimately, even if it isn't scalable, as long as there is a way to solve the customer's problem on each platform, we left the door open to dig into it tenaciously, which I believe is how we achieved such quick user problem solving.
Looking back, the devil was in the details. We managed to secure even small-seeming satisfactions through slightly different solutions per platform for customer needs that seemed impossible to crack.
One more thing I want to say! The creators themselves don't use it much.
Personally, I view it as negligent when product creators don't use their own products a lot.
I think this is essential for building a product with real affection.
But the way I feel it, I haven't really sensed this kind of love or affection among cross-platform creators lately.
In particular, the two main pillars of cross-platform these days are Flutter and React Native. Google and Meta are their respective creators.
At least Meta used React Native deeply through Facebook and Instagram, and I think people adopted React Native heavily thanks to them leading by example.
People tried it thinking, "Ah, if Facebook and Instagram can use it with this level of performance, it's worth a shot."
However, I hear that Meta's recent huge bet, Threads, was built natively.
At this point, I started wondering, "Has the creator's love faded?"
What I thought was even more serious is Google.
Google supports Flutter, but I've never actually seen it used in any of Google's core services.
(If you peek under the hood of their iOS apps, you can check whether they're using Flutter. I found out that the basic Google Workspace apps, YouTube, and YouTube Music don't use Flutter at all.)
Ultimately, a development tool like a cross-platform framework needs to be actively used and improved by its creators, but with things like this, I felt like trust is bound to drop over time.
Conclusion
To sum up, I don't think whether cross-platform becomes a poison or a cure lies in the technology itself.
More importantly, I think it's about knowing that "you must be able to satisfy the customer quickly, no matter what."
In that regard, I highly recommend you definitely read the "Do things that don't scale" essay.
After that, it's safe to say that deeply understanding the problems you're currently trying to solve is critical.
Things like what domain our current problems belong to, what properties the problems we've already solved have, and so on. In particular, I believe team leads guiding engineering teams need to be intimately familiar with these aspects so they can apply the appropriate tech stack.
If you do that, you won't freeze up in panic when management occasionally asks, "Wouldn't development speed get much faster if we use cross-platform?"
With this detailed understanding, you'll be able to tell whether cross-platform is a poison or a cure for your team's specific situation.
Just like medicine shouldn't be abused or misused, it needs to be applied appropriately.
It varies depending on the problem, but personally, I think starting with a narrow target and a sharp, specific problem natively is a solid approach too.