The trouble is the justification of a subscription is evaluated differently by businesses and customers, and both perspectives are rational. If you’ve got servers to pay for, subscriptions are a very appealing model since it makes the “is this business sustainable” math very easy (and less charitably lots of businesses are after that sweet sweet subscription revenue because it tends to be sticky). As a customer, I think it’s also very reasonable to get annoyed that “everything is becoming a subscription” and say “why would I pay this much for something I might need once in a blue moon.”
GP did say they understand why. Doesn't mean it's compelling from the other side.
'Pay for what you use' (micropayments?) seems under-explored outside of cloudhosting to me. Some small cost per meal solves the same problem while seeming more reasonable (or more obviously reasonable) to the consumer, doesn't it?
Honestly, the servers an app like this would need would be a $3/mo VPS. I'm not arguing about the price, the author can charge whatever he wants, but I don't think he'll get many customers that way. It's a good thing that the server requirements are minimal.
OP mentioned this is a “simple app”. They should follow the example of the author of parcelapp.net, which charges less than 5 EUR a year. That’s 50 k€ per year (judging by the ten thousand of reviews (4.8/5 star average) on the Apple App Store. Without taxes, of course.
> There are servers needed for the app to work, right?
But why?
This is described as "a simple app, in which we listed all the recipes we ever prepared, and it would propose randomly three of them. We would then choose together one of them."
You could, if you chose to, built/architect that in a way that doesn't require a backend at all.
You can use deep link URIs to send a _lot_ of data in a link in an email (like literally gigabytes on iOS). Easily enough data to send each other newly added meals/recipes.
You could also encode recipes in QR Codes, so one person enters a new recipe and the other can scan a QR Code the app generates to grab it - you can get about 4kb into a high density QR Code that'll read reliably off a phone screen.
Use one of those to maintain the whole meal/recipe database on each device, no backend required.
Maybe use a date based PRNG so both ends will pick the same "three random recipes" every day.
Send messages between apps as emails with deep links in them, so one user can use the native iOS "share by email" widget to send a "hey, what do you want for dinner" email, with an app generated message with three deeplinks, one for each random choice. Recipient responds by tapping the deep link for their recipe choice, which opens their version of the app - and the app digs the data out off the deeplink URI to pres3ent a "share your choice" button that also uses the native iOS "share by email" widget to send the response back to the first user.
Tapping links in emails and sharing via email isn't as "nice" as an app with a centralised database and push notifications, but it also has zero ongoing cost to run and you know for sure the developer has no lever to enshittify the service, and has no user PII or usage data to sell to surveillance capitalists.
Hmmm, I wonder if you could do this entirely as a web app?
wfleming|1 year ago
OJFord|1 year ago
'Pay for what you use' (micropayments?) seems under-explored outside of cloudhosting to me. Some small cost per meal solves the same problem while seeming more reasonable (or more obviously reasonable) to the consumer, doesn't it?
stavros|1 year ago
Diti|1 year ago
More than enough to pay for server costs.
latexr|1 year ago
unknown|1 year ago
[deleted]
bigiain|1 year ago
But why?
This is described as "a simple app, in which we listed all the recipes we ever prepared, and it would propose randomly three of them. We would then choose together one of them."
You could, if you chose to, built/architect that in a way that doesn't require a backend at all.
You can use deep link URIs to send a _lot_ of data in a link in an email (like literally gigabytes on iOS). Easily enough data to send each other newly added meals/recipes.
You could also encode recipes in QR Codes, so one person enters a new recipe and the other can scan a QR Code the app generates to grab it - you can get about 4kb into a high density QR Code that'll read reliably off a phone screen.
Use one of those to maintain the whole meal/recipe database on each device, no backend required.
Maybe use a date based PRNG so both ends will pick the same "three random recipes" every day.
Send messages between apps as emails with deep links in them, so one user can use the native iOS "share by email" widget to send a "hey, what do you want for dinner" email, with an app generated message with three deeplinks, one for each random choice. Recipient responds by tapping the deep link for their recipe choice, which opens their version of the app - and the app digs the data out off the deeplink URI to pres3ent a "share your choice" button that also uses the native iOS "share by email" widget to send the response back to the first user.
Tapping links in emails and sharing via email isn't as "nice" as an app with a centralised database and push notifications, but it also has zero ongoing cost to run and you know for sure the developer has no lever to enshittify the service, and has no user PII or usage data to sell to surveillance capitalists.
Hmmm, I wonder if you could do this entirely as a web app?