Local-First Software Is Easier to Scale
65 comments
·July 5, 2025kaycey2022
Why local first and not a native application?
NoTranslationL
I purposely did not set up any infrastructure for my iOS app Reflect and made it local-first [0]. I did it so that I could make the app completely private but it’s come with the wonderful side effect that the product is easily horizontally scalable. The only overhead I have for more users is a busier discord channel and so far that community growth has felt very rewarding.
[0] https://apps.apple.com/us/app/reflect-track-anything/id64638...
361994752
It's amazing to me how we called "box-product" now has a fancy new name "local-first". "Box product" is quite well understood. It has a lot of benefits, but also the business model is harder to get right comparing to cloud services. For opensource projects, that will not be a problem tho.
9283409232
Lot of young people don't know what a box product is. You're showing your age.
namuol
How dare people walk around showing their age. Disgusting!
9283409232
Way to miss the point. They said box product is well understood but it isn't these days.
mkagenius
Three clear advantages of a local first software:
1. No network latency, you do not have to send anything across the atlantic.
2. Your get privacy.
3. Its free, you do not need to pay any SaaS business.
An additional would be, the scale being built-in. Every person has their own setup. One central agency doesn't have to take care of all.
ebiester
And if you’re willing to pay $195 for the package and upgrades of $50 each time the OS breaks the app, we are good. And as long as this software doesn’t have to sync across mobile and desktop. And as long as this is single user software.
Then sure.
mrweasel
Take Microsoft Office, if you just need Word, Excel, PowerPoint, Outlook and OneNote, that's the same price as a two year subscription to Office 365 / Microsoft 365 / CoPilot. That's potentially a good deal, depending on your needs.
Some people have been running Office 2003 on everything from Windows XP to Windows 10. Assuming they bought the license 22 years ago, that's pretty cheap, probably $15 per year. As a bonus, they've never had their workflow disrupted.
privatelypublic
On the other hand, theres 17+ years of security updates missing.... and office macros are a known vector.
carlosjobim
You shouldn't upgrade the OS on a machine with important paid-for software which you are using.
Brian_K_White
I think you missed the most important thing, more than any of those, if there is no service, then the service cannot delete or deny access to your data.
And related, if there is no service, then the service cannot fail to secure your data.
No possibility of a billing or login error, where you lose access to your stuff because they just think your're not current or valid when you are.
No possibility of losing access because the internet is down or your current location is geo blocked etc.
No possibility of your account being killed because they scanned the data and decided it contained child porn or pirated movies or software or cad files to make guns or hate speech etc.
Those overlap with free and privacy but the seperate point is not the money or the privacy but the fact that someone else can kill your stuff at any time without warning or recourse.
And someone else can lose your stuff, either directly by having their own servers broken into, or indirectly, by your login credentials getting leaked on your end.
jeffbee
> the service cannot delete or deny access to your data... the service cannot fail to secure your data.
You, on the other hand, are much more likely to do one or both of these things to yourself.
hansvm
If we're tallying such things up, I've had those sorts of major issues with Trello, Google, Navionics, FitBit, FixD, and a number of other companies over the years. My local data on the other hand has had zero issues.
scott_w
I’ve seen this happen in a previous job where the IT team of a customer deleted years worth of financial records because they didn’t know about it when they cleaned up the server. Our CEO had to go and help them rebuild their books, at great cost to the customer!
nicce
All of those advantages are also reason why businesses don’t adapt it…
esafak
It's open source, you "just" have to help write it!
echelon
This entire paradigm gets turned on its head with AI. I tried to do this with purely local compute, and it's a bad play. We don't have good edge compute yet.
1. A lot of good models require an amount of VRAM that is only present in data center GPUs.
2. For models which can run locally (Flux, etc.), you get dramatically different performance between top of line cards and older GPUs. Then you have to serve different models with different sampling techniques to different hardware classes.
3. GPU hardware is expensive and most consumers don't have GPUs. You'll severely limit your TAM if you require a GPU.
4. Mac support is horrible, which alienates half of your potential customers.
It's best to follow the Cursor model where the data center is a necessary evil and the local software is an adapter and visualizer of the local file system.
datameta
Define "good edge compute" in a way that doesn't have expectations set by server-based inference. I don't mean this to sound like a loaded request - we simply can't expect to perform the same operations at the same latency as cloud-based models.
These are two entirely separate paradigms. In many instances it is quite literally impossible to depend on models reachable by RF like in an ultra-low power forest mesh scenario for example.
echelon
We're in agreement that not all problem domains are amenable to data center compute. Those that don't have internet, etc.
But for consumer software that can be internet connected, data center GPU is dominating local edge compute. That's simply because the models are being designed to utilize a lot of VRAM.
cyberax
> This entire paradigm gets turned on its head with AI. I tried to do this with purely local compute, and it's a bad play. We don't have good edge compute yet.
Your TV likely has a good enough CPU to run a decent model for home automation. And a game console most definitely does.
I'd love to see a protocol that would allow devices to upload a model to a computer and then let it sleep until a command it received. Current AI models are really self-contained, they don't need complicated infrastructure to run them.
myflash13
Closest thing to true “serverless”: entire MVC app (Django/Rails/Laravel) in the browser with WASM and data persistence by SQLite over CDN.
All the server has to do then is serve binaries, all the business logic is in the client.
bcoates
What's WASM adding here? Without that you're just describing an ordinary SPA+CDN
williamstein
WASM adds the ability to run a local copy of SQLite (or even PostgreSQL) entirely in the browser.
myflash13
The ability to port existing apps to serverless. See for example Wordpress in WASM.
gjsman-1000
Brilliant… but now you need to validate that the client did all their business logic correctly without tampering. That alone can be so complex it defeats the point.
justinrubek
No... you don't need that. Not for the overwhelmingly vast majority of cases. Let people use their own software. Tampering? Not my problem. Let people do it if they want.
Terr_
The "overwhelmingly cast majority of cases" will be an employee of a larger company, a person/computer that cannot be trusted with arbitrary access to data and exceptions to business rules in code.
kevmo314
Anything that involves sharing data with other people will run into issues around updating. If your API surface is a shipped sqlite db instead of an API call it's liable to be abused in so many ways.
gjsman-1000
Anything that runs as a SaaS, or B2B, has that issue… which is the overwhelming majority of software.
Anything that requires sharing information with other users is also a pain in the neck, as you basically need to treat your internal logic like a proprietary, potentially hostile, file format.
danjl
The reason it's easier to scale local software is that it does not rely on cloud resources. As a result it's cheaper for a startup to distribute local first software since they don't need the infrastructure of a traditional cloud app. The problem is there is no business model for local first software like there is for subscriptions with SaaS. Traditional desktop apps were sold as single purchase items on CDs. That just doesn't work for local first software, since you probably just navigate to a website to get the software.
carlosjobim
> Traditional desktop apps were sold as single purchase items on CDs. That just doesn't work for local first software, since you probably just navigate to a website to get the software.
Did I misunderstand this part? A lot of local software is sold as one time purchase downloads.
vimy
You can just charge subscriptions for local first software. No cloud is irrelevant. Only the value to the user matters.
danjl
Where do you check their subscription in order to cut off the service when they stop paying? One of the nice bits about local first is that there's no need for logins. Do you install security software in your local first app, which, typically, includes the code in a format that's fairly easy to bypass? Pirating desktop software was a big issue for companies. Are we going back to that horrible world?
vimy
A simple license key and monthly ping to license server (5 usd digital ocean) is enough.
Pirates is the cost of doing business. Just ignore them.
No need to make this too complicated.
airstrike
> The problem is there is no business model for local first software like there is for subscriptions with SaaS.
I think this is too broad a stroke to paint with. There's local-first software that still connects to the cloud for additional features. Local-first can enable you to continue to work when offline, but the software can still be more useful when online.
danjl
So your primary technical goal is to do local first, and you keep the cloud because it provides a business model that works? That feels very brittle. The way you're describing it, local first is an optional additional element for a cloud-based tool. I don't think that's the primary intent of the local first movement.
al_borland
Developers can charge money, or subscriptions, for local apps as well. They can probably charge less, as they don't have a cloud provider to pay to host everything. This is pretty common with mobile apps.
spauldo
It depends on your customer base.The SCADA world is largely local, and believe me they have no trouble selling subscriptions.
mrweasel
Their customers would probably prefer that there where no subscription though.
deepsun
I remember Skype was local-first. I believe it was the only one commercially successful P2P project.
But over time and multiple hard-to-recover incidents they switched to cloud.
danjl
Sure, you can try it charge subscriptions, but what are you actually charging for? You're not storing any of the customer's data or providing a service that they need, since the software should work entirely without your help. Fundamentally charging a subscription without having a centralized server is pretty tricky. Even the traditional desktop apps that transitioned to the cloud, like Photoshop or Maya, have really worked hard to beef up their cloud-based service to justify the subscription fee. A mismatch between your business model and your technical infrastructure is not going to stand up well over time. Don't get me wrong. I'm just trying to figure out what business model works for local-first software?
Calavar
I think subscription models became associated with SaaS because cloud hype was at its peak around the time the first big corps were first migrating their products from perpetual licensing to susbscription, and just being on the cloud was seen as a selling point weighty enough to justify the price bump.
Now that cloud hype has died down, I don't see why subscription based would not be viable just because your product runs locally (assuming that all your competitors are already subscription based). ZBrush started selling local first subscriptions, so I guess we'll see soon enough whether that works out for them.
thaumasiotes
> But over time and multiple hard-to-recover incidents they switched to cloud.
My understanding was that they switched to being centralized because phones couldn't run the decentralized version.
thaumasiotes
> Traditional desktop apps were sold as single purchase items on CDs. That just doesn't work for local first software, since you probably just navigate to a website to get the software.
How does the reason you provide support the idea you provide it in support of? There are an infinite number of things that are sold as single purchases that you buy by just navigating to a website where you make the purchase.
There are an infinite number of things that are sold as single purchases on CDs that you buy by just navigating to a website where you make the purchase.
samwillis
Local-first is the true server-less and your device is the real "edge".
So much truth to this post.
iwontberude
Can we go back to native apps yet?
kylecordes
Local first is easier to scale technically.
Paid hosted software is easier to scale financially.
Without the latter, it's very hard to come up with the money to pay people to build, to support the market, etc.
lazyhideousarom
"Lots of cloud providers like to brag about being able to scale with their users. I like to brag about not having to scale at all"
Bars.
colesantiago
While local first software might be easier to scale, the financial aspect remains unsolved.
I can see that Harper (The author's software) was acquired by Automattic so I assume that Automattic is paying the author to maintain Harper, effectively subsiding the maintenance costs to keep Harper free.
Not every local first (and open source) software has the opportunity to be supported by a big company.
lazyhideousarom
"Lots of cloud providers like to brag about being able to scale with their users. I like to brag about not having to scale at all."
Bars.
Local first apps have some peculiar technical features, yes. I worked on CRDTs from maybe 2008 and in 2012 we made a collaborative editor. Local first, all data on the client, syncing by WebSocket. I remember when we debugged it we once had a problem resetting a document. It kept reappearing. The guilty was an iPad laying on the table face down. It synced all the data back. That was seriously different from e.g. Evernote that was losing data all the time. In our system, intentionally purging was really difficult.
Once we ran two weeks with a "poisoned" document that was crushing any server it was uploaded to. The user kept the tab open just working like nothing was happening. Then, we found the bug, but in theory we may have made the entire cluster restart all the time. Apart from electricity consumption, that would hardly change anything. The load and syncing time would be worse, but not by much.
With local-first, everything keeps working even without the server.
Here is the 2012 engine, by the way:
https://github.com/gritzko/citrea-model