I just finished my last week at Expo. For the past nine years, this project has been the center of my life.
I discovered the early Exponent app when I was a teenager. I started building everything I could think of, from small apps to games. Getting to actually join the team at 19 felt unreal. The thing I'd been obsessed with became the thing I got to work on all through my twenties.
It's been amazing to watch how much Expo has grown, and I want to thank the community for the support you've given us over the years.
When I started, Expo did about 25,000 downloads a week on npm. People were building prototypes, games, and weekend side projects. Lots of them were first tries and hackathon demos.
Fast-forward to today: Expo is at 5.6 million weekly downloads. We went from no business model to cash-flow positive with a $45M Series B. The open source under it powers thousands of the top apps on both app stores. Expo Go lives in the top 10 with 4.8 stars. The promise we kept is the one we started with: all you need to build an app is a great idea.
It was the hardest, most rewarding project I've ever been a part of. I came in as a young engineer and left as a leader, recruiter, and — perhaps most importantly — professional yapper. I've learned a lot over the years, and I'd like to share some of it with you.
When I discovered Exponent, I couldn't put it down. I built everything I could think of, and I never really stopped. I'm still doing it today. That obsession turned out to be the most useful thing I brought to the job, because if you use your own product constantly, you feel every rough edge before anyone has to report it.
It sounds obvious, but you can always dogfood more. And the real signal is noticing when you don't use it, then asking why. Every time I caught myself avoiding my own tools, there was a list of subtle problems hiding underneath.
With Expo, that bottleneck kept moving.
First it was how long it took to create a project, so we made that instant. Then it was too many questions during setup. Then scaffolding the basics, then deploying to the store, and now it's build times. Every time you fix one, you have to zoom back out and feel the whole process again, because the next papercut is always waiting.
A lot of that friction hides in decisions the tools force you to make too early. The best lever I found was turning "irreversible" decisions into Type 2 decisions.
An example is when we rethought the iOS bundle identifier: Xcode makes you choose it up front, before you know anything about the project, and warns you it can never be changed. That made sense when deployment took days or weeks. But most "irreversible" decisions are really just a measure of how long something takes to undo, so we made creating and recreating an app nearly instant. Don't like a choice? Just redo it in seconds.
To the average user, that's one or two fewer inputs. But I'd made thousands of projects, and every repetitive prompt was nails on a chalkboard. It's hard for a quick copy to really capture all the finer points without relentlessly stressing the details.
People are usually right about what's bothering them, but rarely articulate exactly how to fix it.
For a long time, Expo gave everyone the same fixed runtime. The more I used it for real projects, the more I hit the same wall: I couldn't add my own native code, and every feature we shipped got forced into every app, even the ones that didn't want it. So we sat on this huge backlog of "please add this library" requests. Adding one would make a handful of people happy but quietly tax everyone else. The advice going around was "don't use Exponent, you'll outgrow it eventually," and honestly they weren't wrong. The backlog was so scary I dressed as it for Halloween one year.
Initially, we kept saying yes to more libraries, more requests. It took us a while to see that everyone was asking for the same thing ("add more!"), but what they actually wanted was a runtime that was theirs, not ours. So we stopped growing the fixed runtime and made it generate itself per project, from whatever you happened to install. It took months, but once it shipped, most of the backlog just disappeared. People could build exactly what they needed without asking us first.
It's tempting to treat every request as a to-do and just grind through the list (now more than ever), but saying yes to everyone is its own kind of trap. Sometimes you have to step back from what people are asking for and solve what they actually need.
When things get hard, you can feel like you have to throw everything out and start over. Software makes that easy, and agents make it nearly automatic.
But writing the code is rarely the hard part. The hard part is getting people to believe you'll still be here next year.
We have a saying on the office wall: Build Developer Trust. Developers are the hardest people in the world to win over; they're used to fixing things themselves, so trusting someone else's tool to do it is a big ask.
The only thing that ever worked was being honest, building in the open, and showing up again the next day. Then repeat, over time.
That's hardest when people are upset with you. The old system ("expo eject") rubbed a lot of people the wrong way, and they told me about it everywhere they could. My girlfriend even brought it up on our first date. Starting over would have been the easy way out.
But we could see what Expo was going to become, basically what it is today, and we kept reminding ourselves that people were frustrated with the work, not with us. I watched this video about No Man's Sky (more times than I'd like to admit): it had a rough launch, then years of quiet fixes, until one day it became everything they'd promised and more.
So we just kept going, one release at a time. A competitor can copy what you built, but no one can copy years of not letting people down. That only really happens if you stay a little longer than feels reasonable, every single time.
On the web you can see if someone uses your tools with a couple of keystrokes. On mobile your guess is as good as anyone else's. For years I only knew someone shipped Expo in production if they told me, which left me relying on vibes. Fun, but the uncertainty ate at me, especially when I'd see some app blow up online.
So one night I put together a system to figure out what the most popular apps were actually built with. It read the trending charts in real time, country by country, and detected the framework behind each app. Instead of measuring the top apps against a million obscure ones, we finally had real numbers.
Two things surprised me: 1) our reach was way bigger than we'd assumed, and 2) the features doing most of the lifting were the "boring" ones nobody posts about, not the flashy ones we spent the most time talking about.
But the most useful part was seeing where we weren't getting traction. Once we knew which categories were working and which weren't, we knew exactly what to build.
It settled arguments too! We'd held off on shipping certain defaults for years, worried they'd bloat everyone's app again — until the data showed people were already pulling in three or four (larger) libraries to do the same thing. No more stalemates.
At some point I had enough plates spinning projects working that the only way to meaningfully scale was to build a great team. You hear "hire slow, fire fast" and "hell yes or no," but those are pretty hard to apply in practice.
What worked for me was simpler: work as hard as I possibly could on the most complicated problems, all the time. Recruiting great people tended to be downstream of that. Hard problems make for exciting work, exciting work results in good content, good content attracts the best people, and together we can go after harder problems. Thus repeating the viciously productive cycle.
It's not especially easy to do, but I found solace in knowing that most of the time it worked every time. What doesn't work is separating concerns. If you don't build, you won't be as good at presenting/selling/marketing. If you don't put yourself out there, great people won't want to work with you.
Last part, which is admittedly the weirdest: a digital persona only gets you a list of great candidates. You still have to interview them. I've written some of my best code while dangerously dehydrated, but this translates poorly to anything interpersonal. Recruiting gets exponentially better when you're at your best. Specifically, when you're at your healthiest: sunshine, hydration, lifting heavy objects. My best recruiting has been proportional to my health. Ultimately, my happiest moments to date have been building a great team.
Remember, attention is finite — every teammate spends some of it, so make sure the cost is always worth it.
When I started down this path, building an app was slow and painful. This morning I built one for my Meta Ray-Bans from my phone, while watching the sunrise.
Expo's moving really fast right now. SDK 56 just shipped and it's faster everywhere. Seeing how close it's getting to apps that mostly build themselves makes me second-guess leaving, because it all just looks really fun.
I've spent my life trying to build things that inspire and excite people. First with Legos, and then with mobile apps. Perhaps for my next act, I'll reach further than whatever's in my pockets.
If you're working on something you're excited about, reach out and tell me about it. Thanks for reading!