As a developer of local applications, I take issue with the notion that apps should be free simply because they don't incur server costs. This argument overlooks several crucial aspects of software development:
Development costs: The bulk of an app's expense lies in its continuous development, not in hosting. Even if backend services can be run for a nominal fee, the time and expertise required for ongoing maintenance, updates, and improvements are significant.
Value proposition: Apps provide utility and solve problems for users. The price should reflect this value, not just the operational costs.
Sustainability: Charging for apps ensures developers can continue to support and improve their products, benefiting users in the long run.
Hidden costs: While server costs might be minimal, there are other expenses like development tools, testing devices, and occasional third-party services that add up.
It's a notetaking app pal, it's not that serious. And certainly not worthy of a subscription model. Kind of ridiculous that they're using this platform as free advertising for what is effectively one of those cashgrab apps.
Amazing project. Would consider buying one, if you sent to Germany.
Did you consider writing your app using the Web Serial API? If you did, why did you decide to go the native route?
> Did you consider writing your app using the Web Serial API? If you did, why did you decide to go the native route?
I went the native route mainly because I love native software, particularly native Mac software. I never quite enjoy using web apps, but I certainly understand the appeal.
Until I get the ordering system taking international addresses, send me an email (support@toaster.llc) with your address and I can send a Stripe invoice.
It appears that the problem is related to the version string transmitted by Firefox Mobile. If they were to send an older user agent string, the issue would likely be resolved. However, any rollback would need to be implemented by Firefox, and it seems they are not at fault here.
From Google's standpoint, this issue may be considered a "new" bug, which means they need to conduct an investigation and address it. Consequently, a rollback is not a viable solution for them.
Why would Firefox have to "rollback" their UA string back to version 64, released 6 years ago (2018)? That seems utterly ridiculous for a server side UA sniffing bug rolled out by the Google Search Team.
Depends on what you consider minimal, but I enjoy working with PocketBase and VanJS[1]. However there is no component library built in (if this is what you were asking for).
Amazing. I was looking for something like this about a year ago. Looks very promising and may be a good drop in replacement for some simple Auth0 use-cases as well as homelab setups.
I was not able to get past „ redirect_uri must be on the same domain as client_id“. Maybe you can give an example of a valid client id for your demo instance.
Sorry, this is indeed not very clear. Others already answered well, but if you look at the example[0] config you can see how you would use your own instance of obligator as a client to the instance running at lastlogin.io. This is a bit meta, but applies equally to any client application.
I recently enjoyed reading https://every-layout.dev. Even though I considered myself to be quite good at CSS, some of the ideas covered in that book (like thinking about how big your elements should be and let the browser handle the breaking instead of relying on media queries) was eye opening for me.
I always recommend https://qrmenucreator.com/ to restaurant owners. I feel it is simple enough for them to get started, gives features like instant changes and comes with a sane default layout/ui and is free of charge.
Payment and ordering would still be done in the classical way, but you get the chance to at least have an always up to date menu with the possibility to reflect when something is sold out or temporarily unavailable.
Development costs: The bulk of an app's expense lies in its continuous development, not in hosting. Even if backend services can be run for a nominal fee, the time and expertise required for ongoing maintenance, updates, and improvements are significant.
Value proposition: Apps provide utility and solve problems for users. The price should reflect this value, not just the operational costs.
Sustainability: Charging for apps ensures developers can continue to support and improve their products, benefiting users in the long run.
Hidden costs: While server costs might be minimal, there are other expenses like development tools, testing devices, and occasional third-party services that add up.