Earlier quoted context omitted.
>you're not monetizing via ads Yes, you are. You can find tons of purely local apps that monetize themselves with ads.
> You can find tons of purely local apps tha[t] monetize themselves with a[d]s. How do they do that without hitting the internet?
Local-first software (2019)
121–130 of 308 posts
Re: Local-first software (2019)
#122Tried to adopt this last month at work, it failed. E.g. the mentioned Automerge, it has poor docs https://automerge.org/docs/reference/library_initialization/... and that left out a lot of question, it seems backend agnostic but have to figure out how to store, how to broadcast ourselves.
Re: Local-first software (2019)
#123Earlier quoted context omitted.
I remember seeing somebody summarize this as "SaaS is a pricing model" or "SaaS is financialization" and it totally rings true. Compared to normal software pricing, a subscription gives you predictable recurring revenue and a natural sort of price discrimination (people who use your system more, pay more). It's also a psychological thing: folks got anchored on really low up-front prices for software, so paying $2000…
Correct. SaaS is a business model, not a technical concept. But the real problem is that there is no equivalent business model for selling local first software. Traditional desktop apps were single purchase items. Local first is not because you just navigate to a website in your browser and blammo you get the software. What we need is a way to make money off of local first software.
Sure there is: “$500 upfront or $21/mo for 24 months *”
* if you don’t complete you 24 payments, we freeze your license.
Re: Local-first software (2019)
#124I held off on playing with Typst for years because I was under the (incorrect) impression that the only way to use it was with their web editor. I'm sure that their editor is completely fine, but I am pretty entrenched in Neovim and Pandoc had been serving me well.
Once I found out that Typst has a command line version that I can use directly, it became more appealing, because I'm pretty sick of cloud shit.
Re: Local-first software (2019)
#125Earlier quoted context omitted.
> I'm sick of everyone trying to come up with a use case to get all my data in everyone's cloud so I have to pay a subscription fee to just make things work. AI photo and video generation is impractical to run locally. ComfyUI and Flux exist, but they serve a tiny sliver of the market with very expensive gamer GPUs. And if you wanted to cater to that market, you'd have to support dozens of different SKUs and deal wit…
> AI photo and video generation is impractical to run locally. You think it always will be? What can the new iPhone chips do locally?
I suspect we're a decade off from being able to generate Veo 3, Seedance, or Kling 2.1 videos directly on our phones.
This is going to require both new compute paradigms and massively more capable hardware. And by that time who knows what we'll be doing in the data center.
Perhaps the demands of generating real time fully explorable worlds will push more investment into local compute for consumers. Robotics will demand tremendous low latency edge compute, and NVidia has already highlighted it as a major growth and investment opportunity.
Re: Local-first software (2019)
#126Earlier quoted context omitted.
Do you know that website? https://www.localfirst.fm EDIT: actually I wanted to point to the "landscape" link (in the top menu) but that URL is quite unergonomic.
No, I didn't know about it -- thank you! (EDIT: and the landscape page has lots of libraries I hadn't run across before. Neat.)
Re: Local-first software (2019)
#127We need a term for a viable business model to pair with local-first tech. I've been working on Relay [0] (realtime multiplayer for Obsidian) and we're trying to follow tailscale's approach by separating out the compute/document sync from our auth control plane. This means thats users still subscribe to our service (and help fund development) and do authn/authz through our service, but we can keep their data entirely…
Re: Local-first software (2019)
#128Whether you need a spinner or not should be decided by the User Experience (e.g., when the user has to wait for more than 100ms, show a spinner), and not by the location of the data. I am a big fan of local-first apps and enjoy building them myself. However, sometimes your app takes a moment to load. With local-first, you eliminate the network as a source of delays, but there are other factors as well, such as large data sets or complex algorithms.
For example, when you have a project planning software and want to plan 100 work packages with multiple resource combinations in an optimal way, depending on the algorithm, this can take some time. In that case, a spinner or a progress bar is a good thing.
Re: Local-first software (2019)
#129We need a term for a viable business model to pair with local-first tech. I've been working on Relay [0] (realtime multiplayer for Obsidian) and we're trying to follow tailscale's approach by separating out the compute/document sync from our auth control plane. This means thats users still subscribe to our service (and help fund development) and do authn/authz through our service, but we can keep their data entirely…
Relay user here! It’s great. Quite reliable for an early product.