Congratulations, Braze! When a Feature Is Actually an Infrastructure Company: Lessons from the Mobile Push Evolution
When Salesforce announced its $5.6B acquisition of Braze, most headlines focused on modern martech consolidation. But looking back to the early days of the iOS App Store—when Braze was known as Appboy—the most compelling story isn't just their growth. It's how a seemingly simple application feature became a multi-billion-dollar infrastructure primitive.
When designing the first SwipedIn iOS app I was thinking about user engagement and re-engagement. We were going to be facing the notorious chicken-and-egg problem and I thought notifications were going to be a great way to overcome it. The problem was that notifications were an afterthought in the SDK and cumbersome. I thought about the notifications that I want in the application, how that might get structured in our company (Superadmin) functionality (or hard-coded), and after conversations with my savant, determined notifications were going to be a rabbit hole I didn’t want my developers going down.
The Developing Ecosystem Gap: Don't Forget the Piping
When a new platform shift takes off, the immediate reaction for most founders is to rush toward building end-user applications. Very few step back to examine the foundational infrastructure and piping that every single application developer is suddenly going to need.
As we looked at integrating notifications for SwipedIn, it quickly became clear that managing them properly was going to be a time-sink. Also, I believed there was a lot more breadth and depth to notifications based on my ideas on how to use them.
When considering how I might implement notifications, I considered looking to email marketing providers and Twilio as existing platform providers who might develop the functionality. I also considered the new kid on the block SendGrid, who I knew from watching all the YC Combinator pitch videos, which had recently launched to create the “Transactional Email” category. I instantly bought into the idea that “Transactional Email” is a category that could be carved out from the email marketing players and thought they might expand into native mobile push. Still, I thought more might be here than people realize, and neither would distract themselves with it.
According to Google (writing this via support from Gemini), “native mobile required a fundamentally different architecture: managing dynamic device tokens, OS-level permissions, and real-time client SDK states. SendGrid didn't move on the opportunity.”
Build vs. Buy: Protecting Developer Velocity & Sharing the Blueprint
Facing that gap brought us to a fundamental rule for startup builders: Keep your developers focused on functionality core to your business.
Writing custom backend logic, administrative tooling, and delivery plumbing for a non-differentiated feature burns precious engineering velocity that should be spent on your core product value.
When Appboy originally pitched us, their product focused on in-app feedback and CRM widgets. We didn't need feedback widgets, so I wasn’t interested in spending my time with them - Props to my CoFouder. He thought their CTO seemed like a genius and wanted to maintain the relationship regardless. But like several early teams giving them candid feedback at the time, I shared the actual problem on our radar:
I think notifications are going to be more strategic than founders and marketers realize, but they're a technical rabbit hole. I don't want my developers getting lost building this functionality. I think there is a lot there. If someone builds dedicated infrastructure for this, that's what we'll buy. I’ll provide them with all of my ideas and feedback to get that built.
This highlights another critical aspect of the build vs. buy mindset: Be willing to "give away" your ideas for roadmap needs that could be their own standalone businesses.
As a founder, you don't need to hoard every adjacent infrastructure problem your app encounters. Handing those problem sets off to dedicated tooling companies helps build the ecosystem you rely on, while keeping your team focused on what actually makes your business unique.
The Appboy team recognized the broader market signal. They pivoted away from their initial product to focus on mobile lifecycle engagement and notification orchestration, building the foundation of what eventually became Braze. SwipedIn became one of the first batch of customers on that new directional path.
Key Takeaways
A "Feature" can become a category-defining business: Never assume an adjacent competitor or legacy incumbent will step in to build native infrastructure for a new ecosystem. What looks like a single utility can anchor a standalone enterprise engine.
Be mindful of when you Build vs. Buy: Keep your developers focused on your core value proposition. If an administrative capability isn't your core product, don't waste internal cycles building it.
Give away non-core roadmap ideas: If you identify an infrastructure need that requires a dedicated team to build properly, hand that problem-set off to founders willing to tackle it. Giving away adjacent ideas accelerates your own stack.
Don’t forget opportunities in the infrastructure in developing ecosystems: When a new platform emerges, look beyond the front-end applications to the underlying infrastructure and tooling application developers need and will inevitably rely on.
Congratulations, Braze
When I was building SwipedIn, I was trying to solve a practical problem for my own business. I didn't want my developers distracted by building notification infrastructure, and I believed notifications had far more potential as a marketing channel than most people realized.
That led me to share an idea with Appboy, become one of the first handful of customers of its second product, and watch that product grow into the foundation of Braze.
The Appboy team took that opportunity and built something much bigger than the original problem I was trying to solve.
Congratulations to everyone who helped build the company. I'm glad to have played a small part in its early history, and it's been fascinating to see how far that idea has traveled.
Comments