How Startup Founders Should Think About Local-First Dev

What Local-First Dev Means for Startup Founders

If you’re a startup founder, you’re always looking for some kind of edge–a way to do things faster or more economically. Local first, which focuses on making an individual dev’s terminal (instead of a cloud-based dev environment) the center of gravity for front-end application development, offers real benefits in development speed and Cloud costs.

Thanks to pioneering research from organizations like Ink & Switch and ongoing interest from the Local First Dev Community, local-first dev has advanced by leaps and bounds, making software faster and simpler to create for many software teams. Prisma founder and startup advisor Johannes Schickling frequently covers the topic on the localfirst.fm podcast. Below, he explains why startup founders should look into local first:

• The Opportunity: Better Life for Devs, Users, and Everyone Else: Local first could mean not just a better life for devs, but better apps for end users
• Removing Data Bottlenecks Means Better UX: Streamlining data bottlenecks gives devs back time to focus on apps that provide users a better experience
• Removing Data Bottlenecks Means Successful, Disruptive Startups: Streamlined, ‘10X’ apps with better UX will have a meaningful chance of unseating incumbents
• How (Or If) to Apply Local First to Your Startup: Currently, local first seems like the best fit for startups building small, sharp tools
• Technical Benefits for Startups - Resourcing, Privacy: Local first can–potentially–mean improved, on-device privacy and being able to do less with more
• Business Benefits for Startups: Faster Dev, Leaner Budgets: Local first can–potentially–mean faster dev cycles and a smaller to nonexistent Cloud budget
• What a Local-First Future Looks Like: Cracking the code on data management could unlock a world where dev is as easy, and creative, as building Legos

The Opportunity: Better Life for Devs, Users, and Everyone

Schickling is bullish on local first’s benefits not just for developers, but for the end users of products that offer local first-like experiences. “A canonical example that's already a success story here is Linear, which is a next-generation product that clearly feels superior in terms of how fast it is and how well the product was executed.”

The project management tool has received praise thanks to its built-in sync engine that resolves changes and conflicts in real time under the hood, even as different users make changes and updates asynchronously. “And it was clearly made possible by a next-generation way to deal with data that was inspired by local first.”

Johannes Schickling explains how local first provides a more-responsive UX at the Local First Berlin conference. Image courtesy Local First Berlin

Removing Data Bottlenecks Means Better UX

While there’s an opportunity to improve app functionality for end users, there’s also room to improve app development. “The modern Web stack is notorious for its complexity–it’s comical how many different tools you have there. But in theory, it should all be very simple. We can run JavaScript on the client or on the server...yet we have this combinatorial explosion of different technologies.”

“A lot of that is constrained, or made terrible, by how complex data management is. Local first has this amazing opportunity to massively simplify the entire application stack, even though one of the golden rules in software development, and in computer science, is usually about conditionals. The answer to most questions is usually, ‘it depends.’”

“So far, we've been swinging this big hammer, no matter which app it is. Most applications we use on a daily basis are built with the same approach. However, local first gives you an opportunity to massively simplify everything and use a more-custom hammer. You can be more efficient, build simpler things, and therefore give application developers the time and affordance to work on what matters most: The app user experience.”

Removing Data Bottlenecks Means Successful, Disruptive Startups

“I’m currently developing a music app which is a very ambitious undertaking, as I'm designing this for myself as the customer, based on the typical ways I consume music. Rather than get too deep into the specific workflows, what’s important is the desire to do better. Application developers want to build better experiences that are credible replacements for the status quo.”

The founder points to Linear CTO Tuomas Artman’s contention that competitive MVPs are all about execution. “[Artman] argues that most products we could think of have already been built. Often, there is already a winner in the market right now. The way to replace that is to build something that's 10x better. And ‘better’ often means making it faster, more reliable, shipping features more quickly, and so on.”

Of course, there’s no magic wand to simply conjure up a 10x product. Building something better usually means making tough choices on what not to focus on during development. “Local first lets me spend my time on something else–making my app better–and spending less time on dealing with data problems.”

“Most products we could think of have already been built. The way to replace that is to build something that's 10x better...faster, more reliable, shipping features more quickly.” -Johannes Schickling, Founder / Overengineering Studios, Prisma

How (Or If) to Apply Local First to Your Startup

Schickling concedes that local-first development is still in the process of maturing through active research, and may not necessarily be a perfect fit for every startup–particularly those looking to actively manage data for thousands of users, or managing enormous, enterprise-grade data workloads with high operational requirements.

“If you think about the way data is managed with local first, it flips the gravity away from huge, monolithic cloud databases that are the source of truth for everything. We now have very capable devices in our pockets that can do a lot of processing and storage. If you think about the photo gallery on your phone, you might want to browse through your images–even if you’re on the subway or a plane.”

“Having challenges accessing your personal memories that are stored in some data center is a very different use case than what a typical enterprise needs. For now, local first might be a better fit for things that are focused around an individual or a small group with a high trust assumption–where it’s fine for someone to access a lot of that data, and you're not as densely connected.”

“Something that would not be easy to build with local-first technologies–a social network like LinkedIn, Twitter, or Facebook is a notorious counterexample. We’re even seeing advancements that help us move in that direction, but that's not where we are.”

“And I think it's hard to say what a ‘typical’ enterprise application would look like. Sometimes, they’re fairly small applications that deal with a fairly small amount of data, deployed in a particular setting on premise or with high trust assumptions. Local first might already be perfectly viable for those use cases.”

“But then, you have another kind of application shape: Something you want to roll out to millions of users right away, and be able to revoke data, and that sort of thing. And this is where it might not be as good of a fit yet. So I think it really depends. But overall, the developments are pointing in a direction where I think local first will become a viable replacement for many more application scenarios than just personal software.”

Technical Benefits for Startups - Resourcing, Privacy

Schickling points to Linear as a case study in how local first can reshape engineering organizations. “The typical software startup has a sizable engineering organization, split across front-end developers, back-end developers, DevOps, and so on. But Linear almost exclusively has front-end engineers because a lot of the other burden is taken care of by a sync engine.”

“If your startup’s situation allows for that, I think this can be a massive competitive advantage where you can keep the team smaller, make the application feel faster, and have many other benefits. However, if we’re not speaking about a hypothetical environment in 10 years, I think it really depends on the kind of application that you want to build.”

“Another interesting perspective on this is when you look at AI, particularly in the context of how to manage end users. This is where AI is meant to serve us, but in a way, it acts like a magnifier for a lot of the problems we're already experiencing. AI can only do a good job if it has great contextual data, but often, that contextual data is even more sensitive.”

“I might be biased because I’m European, but I believe users should really think twice about what kind of data they provide to online services. For example, Apple is a bit like one of the first local-first companies–most iPhone apps are local first, for instance. The company really prides itself on taking user privacy seriously and running AI locally wherever possible.”

“I think more people are picking up on that–that desire to run AI locally, particularly when it's dealing with latency or highly sensitive context.”

“I think [local first] can be a massive competitive advantage where you can keep the team smaller, make the application feel faster, and have many other benefits. However...I think it really depends on the kind of application that you want to build.”

Business Benefits for Startups: Faster Dev, Leaner Budgets

So, does local-first development the ideal technical and business foundation for every single tech startup going forward? “You’d need to do a viability study,” cautions the founder. “If you feel local first is a great fit for the application you’re building, you also need to consider how you will think about evolving the product going forward.”

For startup founders, Schickling emphasizes the importance of optionality–intentionally planning product and organizational roadmaps that don’t overly constrain your company too early in its life. “Local first certainly constrains your optionality in some regard. For example, if a user controls most of the data, and you would like to ship a feature that provides analytical reports across a cohort of users, you might no longer be able to do that.”

“So you need to think through things like: What does your product roadmap look like? Are there other constraints of local first that require you to modify your product? And how much of a problem would that be?”

“If you can determine that local first offers more advantages than disadvantages, making that choice can help you reap the benefits, such as a smaller engineering team, moving faster, and building a faster product–maybe even a 10x better product than what the market has currently to offer.”

“But you also need to see it in the context of where the technology is right now. There is a really interesting product, Muse, that Adam Wiggins built some years ago. At the time, they were very, very early [to implementing a successful version of local first]–maybe too early. They had to do a lot of engineering and a lot of pioneering research work to build this product experience.”

“Maybe if they were a few years later, they could have piggybacked on some of the data engineering work done by other companies–to help them get to market quicker and more efficiently. So if you feel like you'd like to do less pioneering work while you build your product to work around some of the limitations that are still sometimes appearing in those first data stacks, you might be better advised to wait.”

“In that case, you might want to hold off a few years and build it in a traditional way. It's a trade-off in terms of your timing assumptions. That said, [local first] can provide major economic benefits–where you can run much leaner when it comes to cloud infrastructure. In many cases, if you use local first, you simply don’t need cloud infra where you otherwise would have.”

“I think Linear has publicly talked about their [infrastructure] situation. Basically, when you consider the number of customers they’re serving and the impact they're having, they're running on a comically small footprint in terms of infrastructure. I’d guess that if you were to try to build the same sort of product experience in a more-traditional way, you’d probably be easily paying multiple orders of magnitude more in cloud spending every year, compared to what they do.”

“So, if you do the analysis, and you find that you can build your product in a local-first way, then you can expect that the amount of money you need to spend on cloud expenses could be ridiculously small.”

“I would also add that I think there will be a typical ‘Crossing the chasm’ evolution, with innovators, early adopters, and so on. And for all this to become enterprise ready, I think that is still probably a few years down the road.”

What a Local-First Future Looks Like

On the topic of a local-first future for software development, Schickling notes, “I'm personally interested in levers that bring down the effort it requires to bring something into existence. And I think we've seen some of that over the last few decades, like the first availability of the Cloud, or that we can run full-stack JavaScript with WebAssembly (Wasm). And most recently, how AI seems like it might empower entirely new demographics–people who don't do programming.”

“As a kid, I enjoyed playing with Lego, and I’m still nostalgic about the idea of Lego bricks that you can just put together. In theory, that should work for software, but we're not there yet. In my opinion, one of the huge barriers to making that happen is data management. Great applications are still bottlenecked by simple and easy data management.”

“I've studied this field for some time–how much effort it takes to build and continuously maintain something. Previously, projects would just take too much effort to build, and you couldn't justify this effort to the extent of raising VC money, for example. But now you can just do more with less, and that's why I'm excited about it.”

“We’re seeing a lot of promising AI tools–products that might, at least visually, look like the thing I want. But in some ways, some new projects seem very shallow–kind of like the “not hotdog” app from Silicon Valley. You want a real product that does real things, and to make a product real, you need data management that has no asterisks, works reliably, in a sensible way. And this is where we need good building blocks.”

More Resources:

• Article: How Local-First Is Changing Software
• Podcast: The Local First Podcast
• The Local First Developer Community