💻 Local First Dev

In the last couple decades, we've observed the success of SaaS web applications (Google Docs, Salesforce, Basecamp, Trello, etc.). These applications have unleashed collaboration using the web platform. Before this, users might have emailed documents around (many still do this) or shared access to a file-server or used a terminal server to access common infrastructure. However, nothing can match the web for low friction/cost access.

One of the downsides of SaaS is that users need to re-create the context of whatever they are doing in the web application (upload files, copy images, etc.). For many applications, the benefits to collaboration greatly outweighed the cost of re-creating context. For things like issue tracking, SaaS applications work well.

However, for more complex workflows (like CI/CD/PDM/PLM), the drawbacks of SaaS become more apparent because they require much more context. Some products, like Onshape, solve this problem by moving everything to the cloud. This works great for pure mechanical products, but what about electrical and software? Should these all operate in their own silos?

A more compelling vision is a mixture of SaaS and local tooling. Examples include:

Claude Code: while using AI in web sites is very useful, running AI locally in your terminal is a huge step-level improvement for actually doing work (not just answering questions).

Model Context Protocol (MCP): allows AI to connect to local applications and data.

Git hosting apps: Gitea/Github/Gitlab have demonstrated amazing utility for software developers by mixing local tooling (Git, Actions, etc.) with an accessible cloud web application.

Pushing data to the edge is how to scale, and files are the obvious way to do this. While this has always been true, the rise of AI is making this fact crystal clear.