I think treating software as either fully local or fully SaaS is the wrong framing.

There should be a path in between.

For a lot of software, local-first is a much better starting point.

The user already owns a capable machine. Let them use it.

That keeps the barrier to entry low because someone can download the software, try it, and use most of its functionality without the company having to pay infrastructure costs for every action that user takes.

This also changes what developers can build.

Obsidian is a good example. Most of the compute happens on the user’s device, so users can extend the software and run additional processes without every extra workload becoming an infrastructure cost for the developer.

Imagine trying to build something equally extensible as a typical SaaS note-taking application.

If all of that execution happened on company infrastructure, every extension, background process, or compute-heavy workflow could increase the company’s costs.

Then the product has to start defending itself from its own users.

You introduce usage limits, metering, higher tiers, quotas, restricted extensions, or separate paid services simply because every additional thing the user does costs the company money.

That can constrain what the software is allowed to become.

It also changes distribution economics.

With SaaS, even a free user costs money. A generous free tier means subsidizing storage and compute while hoping enough users eventually convert.

A small company may have to burn significant capital just to let people experience the product.

With local-first software, users can experience the product using hardware they already own.

You can potentially keep the software free for the first year, let users genuinely build workflows around it and understand its value, then charge a modest yearly fee for continued development.

You are giving away software access, not subsidizing a year of someone else’s compute.

And software development itself is becoming cheaper and faster with better tooling and AI, which makes this model even more interesting.

Instead of designing the product around increasingly complicated SaaS pricing tiers, developers can focus on making the software better.

Better software attracts more users. More users fund continued development. Continued development makes the software better.

That can compound without infrastructure costs growing proportionally with every action users perform.

But local-first does not mean local-only.

Great production software often genuinely needs cloud infrastructure.

Users want backups, sync across their devices, cloud vaults for seamless collaboration, remote processing, and other capabilities that cannot always live on one machine.

The question is why providing those capabilities should automatically require the software company itself to become the infrastructure operator.

There could be another model.

Users bring the necessary cloud resources, while the software remains local-first.

What we need is a platform with an SDK that developers can build applications on top of, where necessary cloud resources come from the user and the platform abstracts away the painful parts of provisioning, authentication, networking, deployment, storage, and self-hosting.

From the developer’s perspective, they get simple cloud primitives.

From the user’s perspective, it still feels like a polished product rather than running servers manually.

The developer can build cloud-backed features without having to own and subsidize infrastructure for every user.

The user gets local compute by default, cloud capabilities where they actually add value, and far more control over the resources behind their software.

So I don’t think the future should be local-only versus SaaS-only.

Local-first should be the foundation where it makes sense, with cloud added where it genuinely improves the product.

Use the machine the user already owns first.

Use cloud infrastructure when it is actually necessary.

And do not force the entire software business model to revolve around operating infrastructure just because some parts of the product need a server.