The B2B Podcast Index
Index
All categories
MarketingSalesSaaSFinanceHROpsLeadershipCustomer SuccessAI & DataProductStartups & FoundersRevOpsEngineering & DevTools
MethodologySubmit
Best of:MarketingSalesSaaSFinanceHROpsLeadershipCustomer SuccessAI & DataProductStartups & FoundersRevOpsEngineering & DevTools
An independent project byFame
SearchBest episodesGuestsInsightsMethodologySubmit a podcast
Index/Engineering & DevTools/The InfoQ Podcast
The InfoQ Podcast artwork

Architectural Patterns: Moving Beyond Cloud-Native to Local-First - Insights from Adam Wiggins

The InfoQ Podcast · 2026-06-29 · 39 min

0:00--:--

Key moments - from our scoring

Substance score

52 / 100

Five dimensions, 20 points each

Insight Density10 / 20
Originality9 / 20
Guest Caliber14 / 20
Specificity & Evidence11 / 20
Conversational Craft8 / 20

Adam Wiggins brings his decades of experience building cloud infrastructure to bear on a fundamental question: do we need every user action to route through centralized servers? His journey from architecting Heroku's cloud deployment platform to researching local-first architectures at Ink and Switch reveals a pragmatic middle ground between pure cloud and pure local ownership. The episode explores how conflict-free replicated data types (CRDTs) and sync engines - technologies reaching maturity in the late 2010s - enable applications like Linear to deliver instant UI responsiveness by syncing locally-stored data in the background rather than treating servers as the sole source of truth. Wiggins emphasizes this isn't about rejecting the cloud entirely but finding nuanced architectural choices: using local storage for frequently-accessed data while maintaining server coordination for collaboration and backup. He discusses how version control accessibility, real-time collaboration without constant connectivity, and user data ownership emerge as practical business benefits, particularly relevant as remote work and geopolitical infrastructure fragmentation make connectivity less reliable. The discussion touches on AT Protocol, Git's distributed model, and how companies can selectively apply local-first patterns to their software stacks.

Key takeaways

  • →CRDTs and sync engines enable applications to maintain instant responsiveness by writing changes to local storage first, then syncing to servers in the background, as demonstrated by Linear's ticket tracking system.
  • →Local-first architecture doesn't require rejecting the cloud entirely - it's about selective application: keeping frequently-accessed data locally while using servers for collaboration, coordination, and backup.
  • →User agency benefits include control over data deletion and backup, offline functionality, and resilience to infrastructure outages - addressing real business pain points beyond just technical elegance.
  • →Version control primitives like Git's distributed model can be extended beyond software engineering to spreadsheets, documents, and other creative tools, though this remains largely unexplored territory.
  • →The technology is reaching practical maturity for specific use cases like collaborative document editing and team coordination tools, but remains experimental for others like banking systems with strict consistency requirements.

Guests

Adam Wiggins

Topics in this episode

CRDTs (Conflict-free Replicated Data Types)Sync enginesHeroku12 Factor AppInk and SwitchLinear (ticket tracking)AT ProtocolGit and GitHubLocal-first architectureIndexedDB

Questions this episode answers

What is a CRDT and how does it enable local-first software?

A CRDT (conflict-free replicated data type) is a merging data structure that allows multiple nodes in a network - like a user's computer, phone, and server - to maintain their own copies of data and automatically resolve conflicts when syncing, enabling fast local operations without treating the server as the only source of truth.

How does Linear achieve its perceived speed advantage?

Linear stores copies of visited tickets in the browser's IndexedDB, writes updates locally first so the UI responds instantly, and then syncs those changes to the server in the background, rather than waiting for server confirmation before updating the interface.

Why did Adam Wiggins move from building cloud infrastructure with Heroku to researching local-first alternatives?

After experiencing the operational burden of being in the critical path for mission-critical cloud applications, and recognizing users lost control and agency by depending entirely on cloud services, Wiggins saw an opportunity to reclaim some benefits of local file-based systems while maintaining cloud collaboration capabilities.

Is local-first architecture suitable for all software applications?

No - local-first technologies work well for collaborative tools like document editors and project management software with bounded datasets, but may not suit applications requiring strict consistency guarantees like banking systems.

What is Ink and Switch and what problems does it focus on?

Ink and Switch is Wiggins' research lab founded in 2015 to explore operating system-level tools for creation and productivity, investigating how to make version control accessible to non-engineers, improve cloud document collaboration, and design better information processing tools for science and art.

What our scoring noted

Our reviewer’s read on each dimension, with quotes from the episode.

Insight Density

10 / 20

There are genuine architectural insights about CRDTs, sync engines, and the local-first design philosophy, with a solid concrete example in Linear's IndexedDB approach. However, these are diluted by significant filler: long personal anecdotes from the host, a multi-minute tangent on Berlin's startup scene, and generic observations about European regulation that contribute nothing actionable to a B2B operator.

it's first writing that to your local file system and the UI can update instantly. There's no optimistic UI where it's kind of pretending that it's updated just to give the user a quick response. It really is writing into your local storage. And then there's a background thread that's perpetually syncing that with the server
there's a subfield of computer science that's been working on this for 15 years and has really good technical solutions that work a lot better than you'd expect

Originality

9 / 20

The local-first concept is genuinely interesting but the essay coining the term is from 2019, making this largely a re-explanation rather than an extension of the idea. The connection between local-first and AI agent workflows on planes is a fresher angle but is left almost entirely undeveloped, and the Europe-vs-US entrepreneurship segment is completely generic.

small models, open weight models, are not only getting more powerful, but I think we're just learning how to bring them to bear on these kinds of problems
it doesn't have to be a complete rejection of the cloud and, you know, some kind of data anarchy perspective. But there's also a version that I think is kind of the. Where we ended with a lot of cloud things, which is just put everything in the cloud all the time. And that also is too much

Guest Caliber

14 / 20

Adam Wiggins has genuinely significant practitioner credentials - Heroku co-creator, 12 Factor App author, Ink & Switch founder - and speaks from real operational experience including the pain of running critical infrastructure. His current work is more research-oriented than operational, which slightly limits the on-the-ground practitioner value, but he is legitimately influential and not a career podcast guest.

indeed those are Heroku and 12 Factor app, although well in the past now pretty foundational for my career
we wrote the essay that coined the term local first in 2019, although that was after quite a few years of research from folks in the field

Specificity & Evidence

11 / 20

The Linear/IndexedDB sync example is a genuinely concrete case study with a named company and named technical mechanism. Named practitioners (Tomas Aardman, Maggie Appleton, Martin Kleppmann, Johannes Schickling) and conference specifics (sub-200-person first edition sold out in a week, ~400 expected for the third) add texture. However, there are no performance benchmarks, dollar figures, adoption metrics, or failure case data anywhere in the episode.

one of the early movers in this space that really showed uh, what's possible with it is the company Linear...you have in your browser, probably in the index db, you have essentially copies of all the tickets you visited
we purposely picked a very cool. But it was less than 200 people venue in Berlin sold out in the first week

Conversational Craft

8 / 20

The host asks some passable bridge questions linking local-first to AI agents and banking regulation, but repeatedly consumes question time with long personal anecdotes (early-2000s Romania internet, his hardware/software integration headaches) and never once pushes back on or stress-tests any of Adam's claims. Questions are mostly leading or self-answering.

So we as engineers, we over engineer and that's what we like to do. And that's an ongoing discussion I think in all companies they ever work, that we tend to forget the business, um, case at any given moment of time
I remember when I got started so early 2000s Romania, Internet was still a scarce resource and if you had Internet that might have been dial up

Conversation analysis

Computed from the transcript - who did the talking, and the words that came up most.

Share of words spoken

  • Speaker A69%
  • Speaker B31%

Most-used words

software30local24first24cloud23back19data18different16technology14sync13heroku12user12space12started11place11berlin11interesting10

Episode notes

In this episode, Heroku co-founder and Ink & Switch founder Adam Wiggins argues for a 'local-first' architecture that reconciles cloud-based collaboration with the performance and data ownership of local software. He explores the role of CRDTs and version control primitives in non-code domains, and examines how a hybrid AI future might leverage local models for core productivity tasks, challenging the current over-reliance on centralised cloud compute. Read a transcript of this interview: Newsletter:

Full transcript

39 min

Transcribed and scored by The B2B Podcast Index.

Speaker A: The decisions you're making right now about AI adoption, architecture trade offs and how your team works together will shape your systems for years. Getting those calls right when the landscape

Speaker B: is shifting this Fast is hard. QCON San Francisco has spent 20 years connecting senior engineers with practitioners who are a few steps ahead on the same problems. This November 16th through the 20th, 60

Speaker A: plus speakers across 12 tracks will share what's actually working in production and what isn't.

Speaker B: No hidden product pitches, just senior practitioners helping senior practitioners learn more@, ah, qconsf.com. Hello everybody, I'm Olympip and in front of me I have Adam Wiggin. If you're like me, probably you'll not know too much only by the name. So I'll have to name a couple of what he did previously and the two things that probably are more than enough as a cv, uh, for him is Heroku and the other One is the 12 Factor app. So without any further ado, Adam, can you please introduce yourself?

Speaker A: Yeah, thanks for having me. And indeed those are Heroku and 12 Factor app, although well in the past now pretty foundational for my career. Yeah, my name's Adam Wiggins, obviously, uh, a creator of all kinds of software entrepreneur and software engineer and designer and so on. Excited today to talk about local first software but if you go back in time, you know, I got interested in how computers can best serve human needs and that led me through various paths to Heroku, kind of solving the deployment problem and making it faster and easier and frankly more fun to get software out into the world and in front of your users. That led to the manifesto of the 12 Factor app. Following on from that, founded a research lab called Ink and Switch with some of my Heroku co creators and have been exploring the fringes uh, of technology ever since. And again all through this lens of how can computers improve human prosperity and make our lives as humans better, especially for things like art, science, creating things as opposed to consumption tasks.

Speaker B: And also as a ah, early consumer of Heroku, that was quite nice and definitely it was easier. I liked the integration with GitHub at that point and uh, how the things are going but also the detail into how it looked because on the infra side most of the people were okay, it has to work, most of them were using the terminal but Heroku had nice colors and nice naming and you can see that there was a lot of interest into the details and that was what uh, I enjoyed to get started on small projects that then grew but more than that it seemed that all is there. As a purpose and as you mentioned, it's how we can bring technology without being evasive in normal life. Maybe before getting more into your journey, because now we are discussing about local first and Heroku was a synonym of the cloud when cloud native was still uh, a word to be coined. Yet. What are your current projects with Ink and Switch? I had the conversation I think last year around this time with Savannah Kunowski from ideo. They are also very deep into this topic. How to make technology getting closer to the humans and actually adapting technology to the human needs, especially in the interaction. Is that uh, your target as well with Tink and Switch, or is this

Speaker A: broader the charter for Ink and Switch? For me, maybe others involved will see it differently, but the mission to me is always creating the operating system. And I mean that in a pretty loose sense of how we use computers, but specifically for creation and for productivity. So I am sort of weird that I get excited about things like spreadsheets and word processors and calendars and email. These like classic information processing tools that we all really rely on in our daily lives, both for personal things but also obviously to do our work. And the modern information tools are how we create things. Music, movies, but also science, etc. And the tools that are a joy to use and you know, our fit to purpose can help us do these things better. If we can help scientists with better tools, they can have more breakthroughs and that can help us in all the fields that science helps us, for example, uh, but I think it's equally valuable to make better tools for art so that people can write better pieces or create uh, more interesting films, that sort of thing. But I feel like it's often an under invested in area or maybe gets less attention. I think that's changed a bit. You know, we started in can switch in 2015 and back then I think consumer products, social media, e commerce, streaming video, that was really the hot place to be in technology. It was where a lot of the brains went. It's certainly where a lot of the design mindset went. And there's value to that. Of course I'm not against us using computers or people working on that area of technology, but we had the sense that like this is something under invested in. I think that again that's changed uh, since then. You know, maybe you have success stories like, you know, I don't know, someone like Notion or Figma that have come along and said, hey, let's take this, what would traditionally be thought of as kind of a boring tool that doesn't have A very nice user experience that no one thinks much about and make it something a little more interesting, powerful, creative, inspiring. But I still think we have further to go. And so Ink and Switch works in the research space with that broad charter and some of that will be more user facing kind of end products, but some of it will be something like again those operating system level things of like okay, well files have served us well for a really long time, but now we're more in the cloud and we like Google Docs style, real time collaboration and the fact that you can share a document with someone by just sending them a URL. There are some things that are great about files that's especially revealing itself now in the. As AI agents become more popular, can we get some of the same of both of those things? Are there technologies that exist that give us some of the benefits of the cloud and sharing, but also some of the benefits of classic files? Another area of research for the lab, for example, is version control, which I think version control is a foundational tool for all creative work, but really only software engineers have access to it at this point. You, uh, know Git and GitHub have obviously become fairly synonymous with it, but revision control has existed for a long time in our industry and there's small versions of this, you know, lawyers have their redlining for example, and some tools have, you know, version history built in. But it's very, very limited compared to what a software engineers work with. So another track research that David switches on, that I'm personally very interested in, is can we make version control, the primitives of that, accessible enough that anyone could use it? Uh, anyone who's working a spreadsheet or a word processor or a calendar could have the equivalent of a pull request. Is that something within reach of, you know, mere mortals and not just software engineers? I think so, but there's a lot of research, both design and technology to try to tackle that problem.

Speaker B: For me, the biggest challenge in this space, maybe because that's what I'm focusing currently, is how do you bring together hardware engineers, guys that are very focused on electronics and stuff like that, together with guys that are focused on software. And that's my daily headache because you have these guys that know what git means and what the purpose means and what the diff should look like. And then you look at it, you have a new small piece of technology, a small piece of a uh, condenser for instance, that was added to the next version and they cannot see it, I understand with you, because that's Very important to be able to make a difference between different versions. So. Well, good luck with that. Hopefully you'll have a couple of breakthroughs on that as well. But getting back to the clouds or, well, to our laptops, because it feels like it's uh, the Hobbit, uh, it sounds like you journey to the cloud and back again to your local machine. So was it something in the journey of making Heroku a simple and powerful tool for deploying things to the cloud that got you into local first? I understand what you mentioned about the part with Google Docs and the fact that you have something in the cloud and then it's yours, but it's not yours. So at any given moment of time, somebody can unplug it and then you can just paralyze everything that you have. But what was your m, your motivation? What, what are you searching? Uh, uh, on through local first?

Speaker A: Yeah, I like the Hobbit comparison for sure. You know, when we started Heroku, this was before the word cloud was even in use. And of course back in those days especially most enterprise software was written as Windows native apps. The web was finally getting powerful enough as an application platform that people started to build. And indeed this was the business we were in, was essentially, you know, enterprise workflows. Here's a, ah, here's a bunch of inventory in a warehouse that needs to be tracked and there's a database that's the canonical record for that. You need to print out documents and et cetera. And the web had finally become a really great platform for that and the LAMP stack and all that kind of in the 2000s. But the deployment piece of it, especially at that enterprise level, you had sort of shared FTP hosts and so on. And then of course, if you were a big tech company, you'd, I don't know, have your own data center or chunk of a data center. But for that in between space where it's like, okay, we're running a big warehouse, we have a serious software application. Really the answer was you, you rack and stack your own server or a couple of servers. So not huge scale, but you still needed to own that hardware. You needed to order the server, put it together, install it in the rack, install Linux, all this, you know, operations kind of DevOps didn't exist then, but all the operations to just keep it patched and up to date date and deploy things and so on. So we got exposed to that and that motivated us to build Heroku as a kind of way to deploy in a more agile way. You know, the Agile stuff had been happening on the development side of software. The deployment side and the operational side stayed very kind of clunky things took weeks, sometimes months. And so Roku was a solution to that. The idea of, hey, I've got this running piece of software on my laptop now I want to kind of push a button, metaphorically or perhaps actually, and have a version of it that's running on the web and VPS technology and virtualizations and so on was making that possible for the first time. This obviously when Amazon Web Services were first emerging as well. So yeah, we went down this whole journey and I think helped seed or create a concept of what later became serverless. And the idea of trying to make deployment fast, easy, repeatable things like config bars and so on, these are best practices so that you can just get your software out to your users. Because I feel like software that is not in the hands of users has no purpose, you know, running on local host or running on my computer. Cool. But like when you deliver value is when the user can use it. And that was what the cloud really excelled at. And then you go even further to that shared document metaphor again, the Google Docs or the Figma thing where now I can send someone a link and we can both collaborate on it in some way. That was just such a leap forward from here. Let me email you an XLS file and you make some changes and send it back to me, perhaps with uh, a, you know, a slightly different file name. So all of this was a great leap forward and I think we were part of it with Heroku. But yes, it was through that process that I also saw some things that we maybe lost from that more classic file desktop application era. And so on the user side there was that sense of control you can talk about privacy obviously is a huge topic, but also just something like, I don't know, if I delete the file, I know it's gone, or if I want to make a backup, I can make a copy, or if I want to experiment on the file, I can make a copy of that and experiment on that and know the original won't be touched. There was this sense of control and ownership and just agency that came with files that was kind of on the user side. And then on the operational side though, it really was the battle scars of running Heroku, which was we were in the critical path for these huge mission critical applications, sometimes internal enterprise apps, sometimes more public facing ones. And you know, I personally was in charge of kind of that whole thing that, you know, the whole part of the company that was responsible for not only the product and its features, but keeping it online as infrastructure. And the uh, experience of even a few seconds of downtime, let alone, you know, a 20 minute or a 40 minute downtime or something like that, and just very angry people, they're losing money, they're in trouble with their boss, their businesses, uh, you know, it's E commerce business or something. You can literally count the lost sales on your metrics dashboard. And they were right to be angry when we did have downtime. But it sort of left me with this feeling of like, wait a minute, do we really need every single thing that a person, that a user ever clicks on? Does it absolutely have to route through all this complex infrastructure, go all the way to. Realistically then it was, it was east coast United States now hopefully a little more spread out. But it seems odd that we've created such a big stack of things that can go wrong for these very simple operations like checking a checkbox on a to do list or something like that. And so that one, two punch of the pain of being in the critical path of running this infrastructure and thinking we could probably do less of that, and then the user facing side of thinking there's something from files that maybe we lost that we could bring back to the cloud era. For me those two things were the gestation of what would become local first.

Speaker B: So we as engineers, we over engineer and that's what we like to do. And that's an ongoing discussion I think in all companies they ever work, that we tend to forget the business, um, case at any given moment of time and we do a lot more than actually needed. And because in, in us we have like two demons, one of them is very focused on engineering challenges, let's see if we can build that bridge even if we actually don't need it. And it's about delivering value. And I think that's very important because I remember when I got started so early 2000s Romania, Internet was still a scarce resource and if you had Internet that might have been dial up. So you cannot imagine stuff in the cloud. And I think even 2008 when I was doing my studies, it was still a debate about what actually the cloud is. Now it's about the fact that I knew that even if I don't have Internet, I have access to a lot of information, I have documents, I have stuff that I can use. But now if at points there is a hiccup, and now with all the geopolitical battles is going all around A couple of the data centers might be affected. And then if uh, AWS catches a call, the whole Internet is sneezing. And we saw that several times in the last couple of months. But now we got to the cloud and especially in the banking era, uh, now you're, you're based in Europe and you know that there is a lot of regulation and a lot of the banks had huge projects to move stuff from the 70s from the cobals back to the Internet. And now we're going back to them and tell them, okay, now let's go back. Or at least that will sound if you just think about local first. So how would you approach it? Uh, putting back your CTO hat, how would you approach it, how you advise people to look at it, and what would be the main benefits for the users?

Speaker A: Yeah, ah, I totally agree. I think you have to look at the business case also. What's realistic right now. I think it varies a lot by use case. We do tend to think of software and the web and the cloud and so on as being fairly monolithic, but there are so many different constraints or needs you might have for a particular piece of software. Furthermore, it is the case that uh, these local first technologies, which we started to explore and hopefully contribute to, but we're very much on the bleeding edge of computer science circa late 2010s and early 2020s and that's not something to bet your business on. But happily for a certain set of use cases, there are some technologies that have emerged that are reaching a level of maturity now that I would actually bet the right kinds of businesses on it. And most of them are based around a thing called crdts, which is uh, basically a merging type of data structure and sync engines they sometimes call it, which essentially are, you know, we know, sync from things like Dropbox or even back in the day, you know, with a BlackBerry or a uh, or an ipod or something like that. But it's the idea that actually that basic technology of you have multiple nodes in the network, my computer, my phone, my collaborator's computer, the cloud, you know, main server, and that these things, rather than treating the server as just one big central source of authority, and every single other node in the network is just a very thin, very shallow cache. We say, well, what if these individual nodes can have their own either complete copy of a document or a complete copy of a database, or perhaps a more shallow copy of just the records that they need, the pages they have visited. I think one of the early movers in this space that really showed uh, what's possible with it is the company Linear, which uh, is, you know, makes, you know, started making ticket tracking software and has become beloved among developers and kind of is in all the Fortune 5000 now. But one of the things people let me said is how can this thing be so fast? And the answer is that it does this sync process where essentially you have in your browser, probably in the index db, you have essentially copies of all the tickets you visited. And it's essentially whenever you click on something or update something, you add a comment, you mark the status as being different. It's first writing that to your local file system and the UI can update instantly. There's no optimistic UI where it's kind of pretending that it's updated just to give the user a quick response. It really is writing into your local storage. And then there's a background thread that's perpetually syncing that with the server. And of course that immediately leads into questions about, well, how do you handle conflict resolution? And indeed there is a subfield of computer science that's been working on this for 15 years and has really good technical solutions that work a lot better than you'd expect. But again, depends a lot on the domain. You know, for Linear, I think it works really well. People want something that's fast and they have these work groups with these data sets that are on one hand big, but they're not enormous, they're not all the data in the world. And so for them a sync engine was a really good solution very early on. Maybe there's other domains where something like that wouldn't work as well. You know, banking probably is something that, that comes to mind. But the basic idea is having in mind how can I do more on the uh, local device with the server still in almost a, uh, central coordinating role, but, but not necessarily having to be the critical path for absolutely everything. If you start with that perspective and think through your use case on it and look at some of the technologies that are out there, the sync engines and so on, you very often find it's not that you make the whole software stack local first, but there's parts of it this can be adapted to, to get you those business benefits, to get you those benefits for your users in terms of user experience, performance, et cetera.

Speaker B: So the data type that you mentioned, crdt, it's conflictly replicated data type. So that's the base for most of the, let's say sync engines and that makes it available. And based on what you said, what I was Thinking is that another good example of something that, I don't know, a couple of years back you wouldn't have thought, uh, it's possible is BlueSky or the AT protocol just thinking about, well, Twitter, XNow, all that amount of information uh, that is out there, it's impossible to just have it. But the way how AT protocol was designed and thought, it actually provides you that perspective where you do own your data, you can just take it or you can even host it on yourself wherever it's needed. I feel that now we are kind of trying to correct the push for the cloud because we just look into as you mentioned, um, user agency because we still need to use it. And uh, there are all those sass that were just killed or they were unplugged by uh, any given moment of time. And then most of the users just remained looking at the sky without data. Well, they had 30 days. But most of the usual users don't know what to do with it. What should I do? And if they get it, it's something that is just a blob that is not actually the ones that they needed. Ah, and probably you can see that also in the development of Git because you had Git that promised uh, okay, you'll not be reliant on the server anymore as you were in the SVN or CVS days. And we had Git that was distributed and then most of the people are using these days GitLab or GitHub which it's uh, a merger of the two worlds. You can have the distributed, you have the data on your machine, you can work even on the plane, but you still have a place where you can just connect with everybody and see those points.

Speaker A: Yeah, that's well said. And I don't think it has to be either or exactly like that. And Git and GitHub I think shows that. And obviously there's other alternatives to GitHub as well that make different trade offs. But fundamentally you can have a core thing where when I'm working on a piece of software, I want it on my computer, it's mine, I want to be able to inspect the history. I feel like my hands are tied behind my back. If I go to do something and my, I don't know, my WI fi is a little unstable and suddenly sorry, you can't do that, it's wait a minute, this is my software and my computer, why can't I do it? But it's very reasonable to say look, when I need to collaborate with my colleagues, going to the Cloud going onto a website in a somewhat centralized place. Of course that makes perfect sense. So again, it's not an either or. It doesn't have to be a complete rejection of the cloud and, you know, some kind of data anarchy perspective. But there's also a version that I think is kind of the. Where we ended with a lot of cloud things, which is just put everything in the cloud all the time. And that also is too much. And there's some nuanced choices you can make that find a middle ground that gets the best of both worlds.

Speaker B: A lot of the things were just built having in mind proper connectivity because a, uh, big bunch of the users were in very good coverage and so on and so forth. But the period of the pandemic changed a bit the way how we're doing. And people are moving a lot more. They're working from different parts of the world. And then being on the edge is something that is happening more often. And then you can see that a lot of people are factoring that in. And this is one of the things that uh, are becoming cyclical because if you think about all of them were we went to one extreme and then we came back and then we found the middle ground. And the question that is going in my head, and I'll just put it up front, even though it wasn't something that I was planning to ask you, is now we see the same thing happening with agents. After we, we had our autonomy and we developed on our machine, we had IDs that are very powerful. A lot of stuff that was happening and you had most of the tools on your machine and you were able to do it. And then you use the cloud only for syncing purposes, merging a pull request on GitHub or stuff like that. But now we got again to the point where I was just discussing, uh, a couple of weeks back with one coder and he was like, I was very frustrated during my flight. I had uh, a long flight and I couldn't work. Well, what stopped you? Well, I didn't have access to Claude. That was quickly done because it's like something that started not long ago. And what I'm wondering is, when will you get to that point, that sweet spot, when we are not counting tokens, when we are just getting that proper ID merge where you have smaller agents, smaller LLMs on your machine that are doing 80% of your task, and then going back to the cloud only at points. Any thoughts on that?

Speaker A: I mean, I think the way you described it is the exact path that should Be uh, in store for us in the future, at least if I have my way. And again, there's a very good mirror to the data side of it and something like the GitHub, uh, you know, there's places where you need the big servers that have always on connectivity and there's other places where I can just work with local devices. And so I think that small models, open weight models, are not only getting more powerful, but I think we're just learning how to bring them to bear on these kinds of problems. And obviously there's the local first conf, which I'm helping organize and it's coming up soon in Berlin. But one of our speakers there is uh, creator of the PI Agent framework, which is a version of this right. Where if you have a harness that allows you to switch more seamlessly between different kinds of models, different kinds of tools, some of which will require Internet connectivity, some of which won't. And then being on a plane isn't like you're just completely severed from any ability to use the language model assisted coding that has rapidly become core to many of our workflows. But instead you may have restricted capabilities in the same way that I can't collaborate with my colleagues as well when I'm on the plane. But that's okay. There is stuff I can do. I think there's a version of that that is ahead for local models, but because the field is still so new, it's just easier to throw everything in the big expensive GPU compute clusters and kind of send everything to one place. But I very much imagine a more fragmented or ability to choose where I'm sending the work in the future.

Speaker B: Yeah, and you can see that now that the things are moving quite fast. I mean we got to the point where we had the Chromebook because people were actually using most of the services online. So what was the purpose of having a very powerful machine? Now we're going the other way around where you have, where if you look at the top of the line in terms of MacBooks, you do have a very powerful server on your desk and it's pointless to use only browsers and stuff like that. But even though some browsers will not give uh, any names, we'll need a server to keep most of the things cached locally. So I, I do understand why that's needed. But also the GPUs were again an indirection of over usage of another type of resource in computing because in the end GPUs were not considered for these kind of loads. And then they have all those problems and some of the parts with the memory of the agents of LLMs is part of the way how the GPUs work conceived. So now if you look at it, we are moving towards the TPUs that are closer. It's a refinement of the GPUs and those things will definitely be important into upcoming places. But keeping our discussions into our space, I think it's a uh, continuous evolution. And probably the other thing that we have to bear in mind, we did consume a lot of resources with back and forth conversations over the wire that weren't needed. But I think it's an evolution. And as you mentioned, Local first conference is. But it's third, fourth edition.

Speaker A: Yeah, we're on number three here. The backstory is we wrote the essay that coined the term local first in 2019, although that was after quite a few years of research from folks in the field. But we wanted to kind of give it a name that had gotten mature enough but it took a little while before that started to see I guess enough interest among, I don't call it mainstream developers, but let's call it non academics, people who are building software for use in business and real world settings. Industry the academics call it sometimes. And we found that kind of a few years ago there was a uh, seemed like a sudden groundswell of interest. So we held the first edition was 2024, that was a big success and sold out. We realized we needed to expand it so we doubled the size, had another great edition both times in Berlin. And yes, now coming up here in mid July, uh, 2026 we're doing the third edition, um, and I think this one will be the best yet. Although also it's such a different time uh, in the industry. So we're also trying to navigate how do we address all the massive changes that are happening in software development while also really staying focused on our values and what we believe in and what makes Local first and the related communities unique.

Speaker B: And probably it will be worth it to see how the conference evolved. And I think it would be quite nice to understand the focus change of the people that are there. I saw I think another presentation last year in London where there was a small database based on git that's uh, surprising enough and tried to do local first and just saving data like right ahead, log and stuff like that. So I'm just curious to see how did the, the focus areas evolve during these three years and hopefully we'll get the sneak peek of what's to be seen in Mid July in Berlin.

Speaker A: Yeah, I think the first year really was, you know, when Johannes, uh, Schickling approached me to basically say, hey, I think we should do this or we should put on a conference. There would be appetite for it. The idea there was to really see was even there, uh, kind of a community or were there people who could see eye to eye about this? Especially because people come from such different backgrounds. There's obviously that academic computer science part of it, which is, you know, they've been the longest players in the space. But then you have more call it pragmatic oriented people who say, listen, I'm building my react app. I'd like to give a better experience to my end user. Or I'm, um, thinking about, uh, privacy and compliance or maybe even something as just crass as like, hey, I want my cloud hosting bill to be lower. Can this technology help with that? Which is a very reasonable thing. But those people come, you compare that pragmatist and that academic. They come from very different backgrounds. And there's also the research world of ink and switch and malleable software and some of the tools for thought and Doug Engelbart, Alan K. Kind of visionary stuff, which is its own fringy, interesting, unique set of communities, but again has its own values and its own interests. And so that first year putting on the conference, we said, okay, we want to bring these people together. I think it could be interesting to get them in a room together talking to each other, but I'm not sure, maybe they just won't have anything in common or they'll talk past each other. Um, and indeed we were actually worried we wouldn't even be able to fill the venue. So we purposely picked a very cool. But it was less than 200 people venue in Berlin sold out in the first week. And I realized we had made a quite a mistake because then we were in the position of having to turn away great people because we were at capacity. But yeah, really, I really clicked. It was really special. You can actually see all the recordings from past years on YouTube if you want to go, go look for that. But yeah, we had again the combination of people like Tomas Aardman, the CTO and founder of Linear, talking about how it is that the local first sync stuff helps them build their software faster and make it more fun. But you also had someone like Maggie Appleton coming more from a design perspective, talking about how these technologies can help enable what she called barefoot developers, which is sort of, it's in the malleable software citizen developer space. So as you can see, it's like it's always been more than I think just crdts and sync. That said, especially the second year, I think we really went deep in that. We have a lot of new companies, in many cases venture funded companies that are building sync engines, some variation on sync or sync engines or something adjacent to that. So I think last year we went pretty deep on the CRDT technologies, on the sync engines and so on, different trade offs. And that was great. And we see how those companies are getting more mature and their products are more usable. But then going to this year we thought, okay, we want to, we don't want to be just about sync and crdts. As interesting as that stuff is and continues to be an evolving space, there's still unsolved problems in that space and we're still seeing how it plays out in practice. But we wanted to both expand a little bit and the adjacent areas of a local first like identity and authentication is a huge interesting area. But in the meantime also there's all these changes happening in the industry. So for this year we kind of put together the combination of our core base of uh, local first, malleable software, data ownership and user agency. But we're also bringing in things like you mentioned, that proto community, there's some really great energy there. Martin Kleppman, who was foundational and local first also was one of the designers of that protocol that we also have some things from open source community and some things from kind of privacy encryption community. And all of these things sort of overlap in an interesting way and is against this backdrop of this massive shift in how software is built and the role that AI is going to play. And obviously we don't want to be an AI conference and we are not that, but that is going to be a factor in all of this. And so you say, okay, how do we continue to apply our values? We want agency, we want to own our data, we want to own our computing capabilities, but we also want to take advantage of all these great new capabilities that exist. How can we do that? And that is what a lot of the talks are about.

Speaker B: So three years ago it was just the pilot episode to see what's happening. Did you change the venue in the meantime?

Speaker A: We did, we had to. You know, Berlin is such a cool, quirky city in so many ways. And we had, we were in an old theater. You know, you look at the pictures there, it was really quite special. But yeah, it was also limited what we can do space wise. So we went to a A bigger, you might call it more, more professional venue right on the riverside, I'm happy to say. This year we have a venue that's based as part of the arena complex, which is a, uh, Riverside nightclub slash event venue thing. Very Berlin style. Yeah, I guess it has that creative, quirky, rustic, a little weird vibe that you associate with Berlin more than you would say London or San Francisco or something like that, while also being a suitable space to hold the almost 400 people we, we expect to be in attendance this year.

Speaker B: Great. You're an entrepreneur that started his journey in the Valley, probably got to success, uh, in the Valley, and now you moved to Berlin for 10 years if I remember correctly, or something like that.

Speaker A: Yeah, more than that. I might be 12 now actually.

Speaker B: How do you feel about Europe? Is it the right place to become creative because you have more than a decade here?

Speaker A: Yeah, that's a complex topic. You know, I was born and raised in California, certainly found my fortune in Silicon Valley in San Francisco. And so my career owes a great debt of grand gratitude to that place. And I still think that that's a place to go to build your network when you're early on. At the same time, I do think that the problems that software and Internet can solve and also creates in some cases are global now. And I think it would be quite limiting if we can only understand those problems and produce software in one place in the world. So once I had some modicum of success there and had built my network, I wanted to go out and see the world. And Berlin at the time was pretty up and coming for startups Now, I think to some extent the remote work again, once you do have your network, you can be kind of anywhere and the world is full of interesting problems to solve the technology and software specifically can help with. You know, for me it wasn't that calculated. It was that I went out to explore the world when I was in the transitionary time, happened to land in Berlin, worked with some great startups there, and just fell in love with the city. And that turned into just settling and eventually having a, uh, family here. I don't know if it's the most calculated thing for what's best for my career, necessarily. At the same time, I do get exposure to a lot of interesting, different ideas. You know, certainly, for example, the German perspective on privacy and privacy laws is very different from the American one. And I, I wouldn't necessarily say that the cultural mainstream in either of those societies is more right somehow, but more like I have new perspective because I know Both perspectives. Um, and then Europe in general, you know, you ask the question, is it a good place for creativity? I think it is unbelievable as a place to live and for quality of life. And that's why I landed here, why I chose it. You know, the urban lifestyle, the green spaces, riding my bike everywhere, that sort of thing is so, so good for my creative soul. For me personally, uh, maybe others feel that as well. At the same time, I do think there are a lot of weaknesses in what you can do in terms of starting businesses and the amount of paperwork that's required for that and the bureaucracy that goes with that. And of course there are incredible entrepreneurs here who are trying to make change on that. One of the most interesting initiatives to me is the EU Inc. Driven by Andreas Klinger, who's a wonderful Berlin based investor and entrepreneur who sees the problem of, look, Europe could be a powerhouse, an economic powerhouse and a tech powerhouse the same way as the United States. We know that from all the companies that have been founded here over the years. But at the same time you do see this migration that when a company gets serious, they either need to go found a US entity and take venture capital or in some cases the founders moved to the United States. And that seems like a really, really big missed opportunity. I think the zeitgeist is starting to shift on that a little bit in, you know, what it takes to enable entrepreneurs to do what they do and hopefully have that be in balance with the social safety net and the things that people like about Europe. But yeah, I do think that there's on one hand incredible place to live and inspire your creative soul and there's many problems to solve and many intelligent entrepreneurs here. On the other hand, for sure the reputation for bureaucracy and conservativeness and overregulation is deserved. And I think that's starting to be recognized and starting to change.

Speaker B: Yeah, on that point, I think I have two examples in mind. One of them is Demi Hassabi managed to convince Google that he can stay in uh, London and still have an impact on Alphabet and Deep AI was one of the early pioneers of what all, what LLM means. And the flavor that I think it's worth mentioning is the part with ethics because he did put a lot of emphasis on making sure that the AI is for good. And uh, that's what he's all still pushing. And he even managed to put a conference on AI ethics in London. And the other point I think is you can see steps being taken backwards from the European AI Act. It has a real purpose to, uh, just protect people. And there are a lot of things that are important, but I think now they are just taking steps back to make sure that we do have the space for innovation. And that's fortunate. And also I see a lot of push for balance between the social aspects of technology. And that's also quite important from all different perspectives.

Speaker A: Well, maybe I can make a parallel to something you said earlier, which is, you know, I am always drawn to take things from maybe different communities, you know, very Ivy logical, very pragmatic or academic versus builder, and find a middle path or find a nuanced path that gets the best of all. I think where I feel pretty strongly there is a version of that for this realm of things. How do you regulate technology and regulate entrepreneurship? There are many, many great things about the European model and the protections that gives people and the caution it brings. And even something like gdpr, much as it's aligned for the cookie banners and whatever, There are many great things about it in terms of how it created some standards for anonymization of data, created, for example, some standards around the ability to export and take your data with you. And you know that these things that gives people real benefits every day. But at the same time, the American model of fail fast and cheap to get started and cheap to go out of business creates a lot of room for people to take risks and try things. Obviously creates this unbelievable economic dynamism, which is why everything from the Internet to the iPhone was invented in America. So I feel there is a best of both worlds thing that could be constructed were we so inclined or were policymakers so inclined?

Speaker B: Well, I, I do have hope for the future because you are one of the bridges builders between the valley and in Europe. And the other day I had the conversation with Alex Zella, uh, co founder of Edera, and she had the same perspective of we are all under the same sky and we are better together than apart. And I think that's quite important. But we leave that for another coffee conversation because it's too heavy. Adam, thank you for your time.

Speaker A: We covered a lot of ground in not so much time, and I really like that.

Speaker B: And good luck with the conference.

Speaker A: Thank you, Sam.

Related episodes across the Index

Other episodes covering the same guests and topics, from across The B2B Podcast Index.

  • #26 - Adam Fish: Ditto, Realmlocalfirst.fm · on CRDTs (Conflict-free Replicated Data Types)98 / 100

More from The InfoQ Podcast

All episodes →
  • How eBPF Empowers Developers to Observe Inside the Linux Kernel in a Safe and Unintrusive Way
  • Increasing Users’ Data Agency: From BlueSky's AT Protocol to the Local-First Software Movement
  • From MCP and Vibe Coding to Harness Engineering: How Did AI Native Engineering Evolve in One Year
  • Requirements Analysis for Architects: A Conversation with Sonya Natanzon
  • Chasing Efficient Java Development: From 1BRC to Developing Hardwood AI Natively
Explore the best B2B Engineering & DevTools podcasts →
All The InfoQ Podcast episodes →