Subscribe
Share
Share
Embed
Hosted by Matt Klein, creator of Envoy and co-founder of bitdrift, Beyond the Noise goes inside the minds of the engineers, founders, and technical leaders defining the next era of app-based computing. Forget the buzzwords — this is where the people shaping modern systems share how they really build, debug, and scale.
Matt Klein: All right, welcome to another episode of Beyond the Noise, Signals, Stories, and Spicy Takes — the show where we dig into the stories of the people shaping the future of app-based computing with a special focus on mobile. I'm your host Matt Klein, co-founder and CTO of Bitdrift, as well as the co-founder of Envoy Proxy. Each episode we'll talk with engineers, founders, and technical leaders who've transformed the way their companies build and understand what's happening inside their systems. We'll dig into the challenges, the breakthroughs, the lessons learned, and wrap it all up with their hottest takes. So let's dive in.
Today I'm excited to have two guests. This is our first two-guest episode, so we'll see how this goes. First, we have Lauren Darcey, who is a seasoned engineering leader, best-selling technical author, and longtime mobile consultant and entrepreneur. Her career spans leading mobile engineering at scale for companies like Reddit and Vivint Smart Home, as well as serving as a principal engineer across various mobile, fintech, and enterprise security teams before moving into engineering leadership. At her new venture, Infinite Retry Labs, she's reimagining early learning and building a cutting-edge, zero-advertising, kid-centric platform created for active wonder rather than passive consumption or autoplay, powered by modern mobile technologies like Kotlin Multiplatform and AI.
Eric Kuck is a veteran principal mobile engineer, longtime open-source author and contributor, and experienced startup builder. He has a strong track record driving mobile platform architecture, modernization, and developer experience at scale for companies like Reddit, and brings extensive experience from early-stage startups and accelerator environments. As CTO of Infinite Retry Labs, he's focused on creating healthier digital experiences for children and is currently deep into fun, kid-focused, curiosity-driven development using Compose Multiplatform. Thank you Lauren and Eric for joining us.
Eric Kuck: That was a lot of words. Good job getting through it.
Matt Klein: Yeah, thank you. This is our first two-guest episode, so we're going to have to see how this goes. How I typically like to kick it off is I'd love to just learn a little bit about each of your backgrounds, and particularly how you got into the mobile engineering space. It doesn't have to be a detailed career history, but I'd love to learn how you got into computing in general, what got you into mobile, and what excites you about mobile. You can do rock paper scissors to see who goes first, or you can just choose.
Lauren Darcey: I'll go first on this one.
Matt Klein: Okay.
Lauren Darcey: Because I'm a little older than Eric, so he can jump in when we get to his part. I am the child of computer programmers, software engineers, and biomedical engineers, so computing has been a part of my entire life from the very beginning. I was writing BASIC programs when I was in second grade with my dad. I really enjoyed it. I liked video gaming even early on, and some of the text-based Telnet games are where I really got going with writing C++ and things like that.
Lauren Darcey: I ended up in California, in Silicon Valley, for college and stayed after that. This was pre-mobile, so I was basically doing enterprise security and fintech consulting. When mobile came along, I immediately wanted to be writing apps. BREW was my first mobile platform.
Matt Klein: What is BREW? I actually don't know.
Lauren Darcey: Binary Runtime Environment for Wireless. It's what the early Verizon flip phones were using. It was a Qualcomm-based framework with an app store equivalent marketplace. You'd build things in C++, deploy on Qualcomm hardware, get them tested and certified, and work with Qualcomm to be approved for deployment to carriers and sometimes directly to customers.
Matt Klein: And time-wise, this is late nineties, early two-thousands?
Lauren Darcey: Really early two-thousands — 2001, 2002. It was kind of an open secret in Silicon Valley that you didn't need to know much to build these little apps. You needed to know C++, how to get your apps certified and tested, and how to work with Qualcomm. But once you got through those hurdles, you could be a small indie developer. The catch was that all the indie developers were over-inflating how big they were, because that was the only way the carriers would take them seriously.
Lauren Darcey: My husband, who's also a mobile developer, ended up working for a company writing early SMS and MMS clients, which gave me a window into how the whole ecosystem worked. That's when I founded my first company, making apps in that space.
Matt Klein: What did you make? What type of apps?
Lauren Darcey: First, utilities. Some of the first things I built weren't just games — though I definitely built some of those. I built an international converter for sizes and unit measurements, for travel. Like if you wanted to buy shoes in Japan, knowing your shoe size in Japan versus Italy. Fun stuff that was pretty easy to build as a little lookup table.
Matt Klein: I mean, even right now I'm still trying to figure out how many tablespoons are in a cup, so it's a pretty useful thing actually.
Lauren Darcey: Then I went off and built some games where I gave away all the proceeds to my favorite charities. The Monterey Bay Aquarium's otter exhibit was partly funded by a Go Fish game we wrote really early on — one where you could have the computer side cheat, just like in real life. Anyway, one thing I noticed about all of this, as a woman in tech, is how frustrating it is when there's an easy path for people with the right connections and a really hard path if you're missing key pieces of information. That's actually why I got into tech writing in the first place — I was building up this huge amount of special intel that a lot of people were keeping pretty close to the vest, because it kept the ecosystem small and competition low.
Lauren Darcey: As I worked through different mobile platforms, they were all playing the same game: you had to know people, build a network, and pretend to be a bigger company than you were. They were mostly closed walled-garden ecosystems. Then Android came along, and it looked like a really promising, more open, more egalitarian posture than anything we'd seen before.
Matt Klein: And time-wise, this is like 2006, 2007, 2008?
Lauren Darcey: I started doing Android development in the Android beta, so I think 2006 or 2007. I think 1.0 was 2008, but I'd have to check. It's been so long.
Matt Klein: It's also — people listening right now probably can't even wrap their heads around the fact that back then people still went to bookstores to buy books.
Lauren Darcey: We were the last generation of tech writers where the print book mattered more than the digital option. It came out on a CD the first few times we published, then they started hosting them online. That's how I ended up really digging into Android. I had dabbled in J2ME, Symbian, Android, iOS, and BlackBerry around the same time, but Android is where I started watching every single release and trying every single API, basically building out examples for people because nobody was building robust developer portals. No one was explaining how any of this stuff worked. You had to figure it out yourself. That's how some of the worst anti-patterns in mobile came about — no early documentation, no best practices. But it was also a really fun time where you truly had to discover your way into the platform.
Lauren Darcey: That's how I got into Android and how I ended up writing a bunch of books. I've enjoyed the Android ecosystem and community so much that I've mostly stayed in it or adjacent to it for most of my career, though I've also expanded into engineering leadership covering mobile more broadly — iOS as well — and managing backend teams alongside my mobile teams.
Matt Klein: What made you choose Android over iPhone in the beginning?
Lauren Darcey: I really liked Java as a programming language — it was one of my strongest. And I think the open versus closed vibe made a huge impact on me. That difference still exists today, which is funny. But multi-platform stuff throws a lot of that up in the air in fun ways. It's been interesting to watch how the platforms have gained influence over mobile in different ways, and how the balance shifts every few years in terms of who's ahead on certain technologies.
Matt Klein: I've been asking this of almost every guest. It is interesting that both the Android and iOS platforms are now huge, with tons of apps and developers. But the Android developer community, at least from the outside — I'm not a core mobile developer — does seem healthier from an openness perspective. There seems to be more people contributing in the way you're describing. I can only believe it comes from how the community was started, being a bit more open. Is that your experience?
Lauren Darcey: I definitely think so. A lot of the reason we open-sourced all the code for our books was simply so we could use it again ourselves. At the time, if you wrote code, chances were your employer would assert ownership over it. If you were consulting like I was, that meant building something boilerplate and then finding yourself handcuffed and not being able to use it. There were a lot more benefits to working in the open than people feel now. And this was really early open source — you didn't even have a Git community yet.
Lauren Darcey: It was a really great time because there weren't many mobile developers out there. It was a lucrative, fun place to be. You were usually building cool and interesting apps. The big players had fun accelerator and incubator programs. It didn't take much to build a team — if you had a good idea and could execute, it was actually harder to navigate the publishing ecosystem than it was to build something fun.
Matt Klein: Which I think is a good segue to Eric. Let's hear about you — how did you get into mobile, and how did you two find each other at Reddit?
Eric Kuck: How I got into computing is the exact opposite of Lauren. My parents were both in education. I went to a not-the-best high school — all my colleagues now talk about high school classes where they came out knowing multiple languages. My high school had Mavis Beacon Teaches Typing. That was it. So I got into software engineering really just because I like computers. I decided to get a degree in computer engineering — no idea what it meant at the time, but in retrospect, great decision.
Eric Kuck: The way I actually got into software was kind of by accident. I studied computer engineering, which is roughly half software and half hardware. I love microcontrollers and lower-level programming. My first job was at Motorola, where I was supposed to work on embedded systems. I showed up the first day and they told me they were starting this new thing called Android — had I heard of it? They noticed I'd taken some mobile classes in college and moved me over. They didn't even ask, really — they told me.
Eric Kuck: So I joined this team where everybody was just learning this brand new thing. Their entire careers had been in P2K, the old RAZR OS. My favorite example: a very senior engineer demoed one of his apps, and because there was no understanding of Activities, it was just SetView, SetView. You'd click a button, go to a new screen — one activity with tens or hundreds of thousands of lines of code. People didn't know any better. Very quickly I found myself leading teams and showing people how to do things, simply because I had an interest, had done a bit on the side, and taken a college class. Very minimal qualifications, but at the time that's all you needed. Getting back to what Lauren said, the bar to entry was a lot lower. There was a lot less information out there — Motorola had a big library with a lot of stuff on how to program Java, but nothing on how to program Android. It was just brand new for all of us.
Eric Kuck: From there I was working at Motorola, doing a few things on the side. I published some indie apps that took off and realized they could support me. So I left Motorola after about nine months and went indie.
Matt Klein: What was your favorite app from that time?
Eric Kuck: I won't say favorite — most successful, which I'm slightly embarrassed about. Android compared to iOS was a very immature app ecosystem at the time. All the best apps were on iOS. So I went to the iOS App Store, looked at the top apps, and compared what was missing from Android. The number one thing I found was that iOS had great apps to cheat at Words with Friends. I didn't even play Words with Friends myself, so I never really used my own app. But I figured out how to do OCR on Android — I made my own OCR engine, a fast way to scan your letters, identify available spaces, and look things up in the dictionary. It ended up being very successful. Not my proudest moment, but it allowed me to get my career started in the indie space and bridge into the startup world.
Eric Kuck: Until Reddit, startups were really where I spent most of my time. I didn't love the big company environment between internships and Motorola — the process, the slow pace. When you're young and right out of college, you just want to build stuff. So I got really into early-stage startups, went through accelerators, worked with a lot of startups in Chicago where I lived, and eventually built an app development company where I was CTO. We built everything — Uber for dog walking, you name it. I thought that was going to be my whole career. I loved owning the entire stack, doing the design in Photoshop, building it, doing all the testing. It was fun.
Eric Kuck: Then Reddit came calling. I had a bunch of open-source work out there from running the app development company, and Reddit happened to be a big user of one of my projects.
Matt Klein: Which project?
Eric Kuck: It was called Conductor. It was an alternative to Fragments on Android — a way to navigate from screen to screen. Reddit reached out, and even though I'd never wanted to work at a large company again, Reddit was an exception in my head. I took them up on their offer, worked on multiple teams and roles, and ultimately ended up working with Lauren on the Android platform team. I guess the rest is history — and that's also where we met you.
Matt Klein: Yeah, it was a good time. I've worked at very large companies and very small ones, and I've now started two companies. To be well-rounded as an engineer, it's actually useful to work at some of these giant places and also do your own thing. I tend to flourish in smaller, faster-moving environments, but I wouldn't be the engineer I am today without exposure at larger companies to very senior people and bigger problems. I'd assume you both saw a lot of big engineering challenges at Reddit that you hadn't seen before. What were some of the biggest?
Eric Kuck: In my whole time in early-stage startups, I'd always heard about "problems at scale," and in my head I thought — well, it's a mobile app, it doesn't matter how many people are using it, it's still just on the device. Scale doesn't matter. I found out very quickly that was completely incorrect. Everything changes at scale. An issue affecting 0.01% of users is suddenly a lot of users and you need to care about it. Suddenly you have users in countries you never knew existed, or on devices from ten years ago that you had no idea people were still using.
Eric Kuck: The one that always comes to mind is SRM — or cross-exposure, as Lauren calls it. At any decent-sized company, you put feature flags in to make sure only a subset of users are exposed to different experiments while you validate they're working and that users actually want them. Cross-exposure is where the backend tells the app "20% of users should be in bucket A and 80% in bucket B," but you end up with 25% reporting they're in bucket A. With small user counts, that might be within margin of error. With millions of users, it's obviously a big problem. It happened to be by far our hardest engineering problem to solve. It took years.
Matt Klein: Was that a bug in your feature flagging system, or was there bias in the assignments?
Eric Kuck: There were many bugs across many systems that contributed. We'd have someone work on it, say "I found the fix," push it out, and it would kind of work but not really. Then someone else would find a fix, and it was just a cycle on repeat. We could notice patterns — it affected experiments read very early in app startup more than experiments read in the middle of a session. So we had clues and suspected timing issues or race conditions. Lauren, you kind of led the project at many points — do you want to talk about it?
Lauren Darcey: This is an example of definitely a lot of race conditions at scale, but also an area of the codebase that nobody owned, nobody knew anymore, everyone was afraid of, had no tests around it, and had been allowed to get extremely crusty and hard to work in — no clean paths to debug. Every person who went in there found all sorts of things wrong. When you moved one thing, a bunch of other things would break. And you didn't have the ability to fundamentally change the environment you were working in — you had to find surgical solutions to the immediate problem.
Lauren Darcey: Everyone who went in there found really big, gnarly problems and net improved the situation. But that particular area of the codebase should have been rewritten long before anyone had to solve this sort of problem in it. It was also never really built for that kind of pressure — the experiment framework had never been built with the assumption it would be under this much load. There was a lot of "we wouldn't have built it this way if we'd known." And no one on the team owned it. It was a rotating set of people who would find interesting stuff, solve part of the problem, and then we'd have to watch for weeks because it takes forever to get the data.
Matt Klein: The bar for making this type of code correct is very high. Not only do you have to wait weeks for actual releases, but if you're talking about experimentation, you have to wait for experiments to run and then wait for statistical significance. It could be two months between making any change and realizing, "Oops, it's a little better but still broken." I can see how it would take years to fix.
Lauren Darcey: Not only that, these were tiny percentages of users hitting the problem. You might get one every few weeks that actually triggered it — you had to have the right experiment, set up the right way, on the right build. But the at-scale stuff we learned — and this is the part I liked most — is that even companies as big as Reddit are just building operational excellence as they go. Walking in as a former consultant who'd seen many companies and how they tried to fix their problems, I found they didn't have on-call programs for mobile. The assumption was that mobile teams never get that big, they don't need SRE, observability is an afterthought because it's just individual users on their own devices.
Lauren Darcey: But when you work on an app at scale, you realize you can learn really fast — the easy way or the hard way. Because you're deploying to so many people at once, you get signals incredibly quickly about whether what you've deployed works, if you're listening and have good observability. Or you can dark-deploy and be happily unaware that things are going completely sideways. There's this really great learning curve where you realize you can deploy something, get great signals fast, and make changes quickly to learn how to build better or recover faster. You learn this by trial by fire at scale, or incredibly slowly at a smaller company.
Lauren Darcey: When I think about the funny, messy stuff that happens at scale that you don't see elsewhere — you have an experiment going sideways and think "we just turn off that flag and go back to default behavior." But you forget this was a migration between old and new infrastructure. You turn it off and suddenly shed all your traffic back onto the old infrastructure way too fast, and that goes down. Assumptions that things would be easier without scale suddenly reveal that you have a firehose you're directing in different directions, and you have to take careful steps to keep things stable.
Matt Klein: There's scale on two different sides: the extremely large number of users, and the scale of the codebase with lots of developers working on it. During your time at Reddit, was the external user scale a bigger area of focus, or the internal developer scale? Or both?
Lauren Darcey: Both. We were on a platform org, which meant we had a dual purpose. We owned overall app quality — crash rates, stability rates — and we'd be the ones called by on-call teams if mobile was involved. One of my first experiences with Eric was seeing him being parachuted into every incident that had any mobile component — like bringing a gun to a knife fight. It was an indicator that we needed better on-call programs where people owned their own outcomes in production.
Lauren Darcey: Part of the reason Eric joined the platform team was because the internal developer experience at Reddit was not good. It was known outside of Reddit that it wasn't good.
Matt Klein: How was it known outside of Reddit?
Lauren Darcey: Because you'd ask what it was like to work at Reddit on the codebase and people would say, "Our builds take two and a half hours on a good day," or "I have a really hard time deploying my single-line null pointer exception fix." Those problems were pervasive. That's part of why the platform org was built out — they were on a hypergrowth path for internal engineering organizations and feeling the pain of growing internally, just as they were feeling the pain of becoming a globally-scaled app.
Matt Klein: And the internal developer productivity work — I'm assuming that's all the normal issues around build caching, IDE speed, and so on?
Eric Kuck: That was definitely a large focus. There were other things too. It started as a very small team that could keep the whole app in their heads at once. If you know where everything is, organization is less important because you just know where to look. But once you get to sixty or eighty-plus developers and many hundreds of modules, there's no way anyone can keep it all in their heads. Organization, architecture, familiarity, and common patterns become much more important. It was a dual effort to modernize how we built the app and bring it all together so that if you had to insert a feature into, say, the main feed, the codebase would feel familiar — it wouldn't be like learning a brand new codebase just to make a small change.
Lauren Darcey: One thing I learned from Reddit is that if you put off your developer experience, your teams will find a way to ship — and you might not like how that shows up in your codebase or processes. Eric and I both like the ability to not follow rules that don't serve a real purpose. When you have really bad developer experience, you start seeing people putting massive PRs through because they only want to go through the review process once. Or they're not willing to work in the same repo and follow the same testing rules as everyone else because they need fast cycle times on their builds — so they've built their own little bubble. Eric is one of those people.
Lauren Darcey: When you start having a vision for how things should work, and you're also hiring a ton of contractors who need to onboard quickly, you need guardrails. What we did well was provide a set of rules and guidelines that helped everyone build better together, without being heavy-handed. It wasn't "you violated the rules" — it was more "if you follow our golden path, you'll get really good tools from us that make your life easier and give you high ownership of your areas." We'd ask you to join the monorepo and put tools up that gave easy access to sample apps and fast cycle times. We wanted everyone in the same pool so we could apply consistent rules. That consistency helps with things like AI integration later on. When you're shipping your org chart across 800-plus modules with many more modules than people or teams, and no easy way to take things out once they're in, those are the kinds of capabilities you actually need.
Matt Klein: From a platform team perspective, to be successful it's like any other product — you have to meet your customers where they are and dangle some carrots to get them in. Before we talk about your new venture, I want to touch on something we haven't covered yet: mobile on-call and reliability. On the server side, we now have twenty or thirty years of people learning how to operate systems and a general appreciation of on-call and SRE practices. But it continues to utterly shock me that, even today, there's a fairly poor appreciation of what end-to-end reliability means on the mobile side. There's no such thing as an MRE — a Mobile Reliability Engineer. What do you think about that? Is it true?
Lauren Darcey: I can rewind to Vivint Smart Home for this, because they're an IoT company and they actually had backend platform teams embedded with their mobile folks quite often, in a way I didn't see as much at Reddit. They had specific high points of the year — seasonal times when things got really dicey and became great postmortem opportunities. Smart homes have doorbell cameras that get rung a lot on Halloween, Thanksgiving, and Christmas in ways you never see the rest of the year. Retail companies care a lot about Black Friday. I learned a lot about operational excellence from having those folks embedded together.
Lauren Darcey: When I joined Reddit, we were dark-deploying weekly to 100% of users and not really looking at our observability — not even aware we were causing problems until users told us days later after they'd adopted the release. By that point, it's really hard to navigate. So early on when building out the on-call experience for the platform teams, we basically went and stole all the good ideas from the SRE teams. We couldn't get alignment on actually having those resources embedded, so we stole their incident playbooks and adapted them to mobile.
Lauren Darcey: What's interesting is there are a few places where we differ a lot. Backend teams are used to deploying small pieces of work and reverting them. Mobile packages up a huge number of PRs every week and ships them all together through an app store review process that can be a real roller coaster, with an unclear delay in reaching production even for big companies. So what do you do when you can't revert a change in production easily? You build very extensive feature flagging, very extensive vetting processes, and different testing scenarios. We made the most progress when we adopted foundational SRE ideas: blameless postmortems, making simple changes whenever possible, and isolating them from other things — especially for hot fixes.
Lauren Darcey: But we'd always run into the issue that backend SRE teams haven't learned how mobile is different, and mobile teams haven't fully learned how backend is different. There's so much middle ground where we could be innovating but aren't, because those groups rarely experience the pain in similar ways. We eventually had to write documentation stating: "You cannot revert a mobile release once it has gone through the app store. You may only fix forward." But every single incident, if an SRE showed up, they'd say "why don't you just revert that little change?" And the answer was: you can't. That is not an option in this system.
Lauren Darcey: So I feel like there's so much cross-training capability we're leaving on the table. Instead, everyone builds their own observability in their own different places and doesn't know what's happening to each other. Quite frequently, one hand doesn't know that the other has deployed or not — in both directions.
Matt Klein: It's even — I'll segue briefly into a company anecdote. We have feature requests from people where it'll go something like "our mobile people want to look in Bitdrift, but the server people don't." That's fine — I get that some people want a single pane of glass, which I don't think will ever exist, and others want to go into different systems. But it's an indication that even at very large companies, mobile and backend still don't really talk to each other. They operate in completely different systems. It's not even a technical question — it's an organizational and leadership question that I find fascinating, because it seems so counterproductive for the end-user experience.
Lauren Darcey: It's worse than that. We did a lot of large-scale migrations where you'd end up having to write runbooks for the old infrastructure and the new, and you couldn't even debug without first asking "are we on a REST endpoint or a GraphQL endpoint?" You'd actually page different people depending on the answer. Sometimes it ended up in really funny places — like when the feed was being served from one infrastructure and the ads from another, one of them went down, and suddenly the app was only ads. We got roasted for that, pretty reasonably. You'd hear about it and think, "I don't even know who I'm supposed to page — the one that's up isn't causing the problem, it's the one that's down."
Lauren Darcey: There's also a lot to learn in mobile observability, but you can take it too far. When you have good enough observability to tell you something is wrong, you probably don't need three more digits of granularity to know what the action is. You don't just turn on really verbose logging because you can and because data is nearly free — it still impacts your performance. All that ad data also impacts your performance, and those things add up. We've actually found that removing some of those things improved the outcomes we were trying to improve.
Matt Klein: You're preaching to the choir. Eric, anything to add on this topic before we talk about your new venture?
Eric Kuck: A lot of mobile developers have this standpoint of "I don't need to be on call — the app isn't changing right now, I can't push anyway." The reality is I don't think I've ever actually not been on call, even when I haven't thought of it that way. Even as an indie developer, you're spending a lot of time looking at your reviews and analytics, trying to figure out if something's going on. Formalizing it was fantastic. As a mobile developer you might have a gut feeling that you don't want to be on call, that you want your nights and weekends. But the reality is you probably are on call to some extent anyway, and formalizing it just helps you so much — having a process, knowing who to call, who to talk to.
Lauren Darcey: I want to add to that. We ended up having way better morale when we had a dedicated person in front of the interrupts, surprises, and drama. Their only job was to stabilize things and coordinate what needed to happen. That was a legitimate role for an engineer. The teams without those structures were often the ones burning out — they could never step away or take a vacation, and it always fell on the same few people who got really good at debugging prod issues. That's a whole different set of cultural problems. For that reason alone, having a set of dedicated plans around how you solve things is invaluable. Over time, we got so good at solving problems and so efficient about how we communicated in Slack that they didn't escalate into big issues that consumed whole teams. They'd be solved before anyone even realized a problem was brewing. And you don't learn any of that without building simple runbooks, simple plans, and knowing who to call.
Matt Klein: I apologize for taking this long to get to your new venture — we'll probably have to do a follow-up episode. But could you briefly tell us what you're both up to now?
Lauren Darcey: Sure. We are building a platform for kids. We're both parents, and we've noticed that app options for parents and kids pretty much suck. They kind of always have. As mobile developers, our answer has often been to just build them for our own kids. But you learn a lot about mobile in general when you build for a really underserved type of user — a user who can't navigate by reading and doesn't know how to count. It makes you a better engineer. You're forced not to use the default answers to everything. If you've been around mobile since the beginning, you know that a lot of those defaults are accidental. We got hamburger menus and just stuck with them. They're ugly and functional, but you probably wouldn't build them that way starting from scratch today — they exist because of where we were with device capabilities and available resources at the time.
Lauren Darcey: There's also a lot about how developer ecosystems work that encourages behaviors that aren't healthy for kids — or for adults, honestly, but especially not kids. Add ads, and suddenly you're an engagement and stickiness company whose business model is basically selling one customer to another. If you're going to look for a giant market to disrupt with lots of opportunity and the ability to build fun things using future-facing technologies, the kids space looks pretty good as a place to plant yourself as a startup.
Eric Kuck: It's definitely fun. We're experimenting with a lot of things we never would have gotten to otherwise. We're not going all the way back to skeuomorphism from the early iOS days, but there was a reason for it — the notes app looked like a sheet of paper, the contacts app looked like a leather-bound book, because it helped people get familiar with mobile concepts. We're now dealing with a market that isn't already familiar with those concepts, where flat design doesn't necessarily mean the same things, where users can't read, where the concept of a bottom sheet as a dismissable modal makes no sense. So we get to rethink a lot of really cool things — lots of animations and fun interactions we haven't gotten to do otherwise.
Matt Klein: So right now it sounds like you're starting by focusing on fundamental usability issues. Are you doing that in the context of a set of initial pilot apps?
Lauren Darcey: We have lots of app ideas and prototypes built out. Pulling them together into a product is something we're working on, but we're basically looking at the building blocks you need to build lots of different things in this new way. Because of our interest in the open-source community, we also want to contribute to it more and change the ecosystem so other people can build lighter-weight apps that don't immediately focus on tracking or monetization. Making those easier for anyone to build seems especially important right now, with a whole new wave of vibe-coding mobile developers entering the market. I don't like the momentum that exists in the ecosystem and how those developers will build in the future if it's the same way we've been building up until now. So how do you introduce new building blocks that make it easy to revisit certain decisions?
Matt Klein: My perception is that parents are willing to pay for apps more than most people are, and if there were apps that weren't total garbage, people would pay for them without needing ads.
Lauren Darcey: I think that's true. But so many apps right now are doing two really interesting things. Giant brand apps are getting to the top of the app stores, and all the apps around them have ads in them — ads for that top app. So the first thing you see when you launch a secondary app is essentially "go install app number one." You're just cannibalizing your own category, leaving users with one option. The other thing is that the value proposition for parents when a child wants to pay for something is often just that you're paying your way out of the ads themselves. There's no other value — same experience, fewer ads.
Lauren Darcey: What's really scary is that low-income kids can't pay their way out of the worst of what the app ecosystem has to offer. They're stuck with the ads — and sometimes really bad ads — in apps they maybe shouldn't be in at all. I've never been so discouraged from entering a category as when I told people I was going to mess around in the kids space. They'd say "there's so much compliance, so many hurdles, and nobody wants to pay." And I'd say: they'll pay for value if it's actual value. It's a much cleaner monetization strategy than "it's free, but I'm selling you to somebody else." There's a lot of interesting building block work to do here. And we have a bunch of prototype experiences for kids that we've tested with real kids that go over really, really well — with the kids and with their parents. So figuring out how to tie it all together with a good navigation system and deploy — that's the plan.
Matt Klein: Do you have a timeline for your first big launch?
Lauren Darcey: I want to be deploying something to a broader beta in the first half of next year.
Matt Klein: I have two kids who will be your beta testers — just let me know.
Lauren Darcey: Navigation is the hardest challenge for us, other than the user model for the parent-child relationship when they're not on the same device. Those are the two things we're still innovating on before we'd want to deploy something bigger.
Matt Klein: We're unfortunately at the end of our time. I'd love to come back in six months or so and learn more about this topic. Eric, anything to add on the new venture?
Eric Kuck: No, that was good.
Matt Klein: Okay. Thank you both — this was a fantastic conversation. That's a wrap for this episode of Beyond the Noise, Signals, Stories, and Spicy Takes. Huge thanks to you both for joining and sharing your stories. You can find this episode and all past ones on the Bitdrift YouTube channel. If you had fun, drop us a review, tell your friends, or yell your favorite hot take into the void and just make sure to tag us. I'm Matt Klein, and I will see you next time. Thank you both.