I downloaded SnapCalorie to try it out on Android. I went all the way through the sign-up phase, only to discovery that I would need to activate subscription in order to have the 7-day trial. Ended up uninstalling the app :(
We're an early stage startup and the models are expensive, we're trying to get the price as low as possible, but yes we need to charge to cover costs right now. Sorry about that!
You might get a yearly discount offer that is less than $2/month if you get lucky (A/B test split). But that's less than the cost of running the model for people, so hopefully others will consider paying full price.
Thanks for you quick answer. I want to clarify that I would have liked to try the app for a few days before activating subscription.
Now with the current flow I would need to activate the subscription and then immediately go to Play Store settings to deactivate the subscription so that I would not forget it.
That's pretty standard for free trials in my experience. Amazon prime, audible, musescore, I'd be harder pressed to think of a service I've recently tried where it was not like that.
We don't discourage anyone from doing this! Free trial with access to all features stays live for the full 7 days even if you cancel immediately. Hope you enjoy it.
I'm on an annual plan from another app (Calory, $30) otherwise I would have bit.
It gives some features with a totally free plan. That makes the IaP feel less like a bait and switch.
The proposition of SnapCalorie is compelling. Calory ui is decent and I use a scale so accuracy should be good but I think their database is shitty. Meatloaf will vary from 1.5 kcal/g to 3, steak will show as 1 kcal/g, stuff like that.
You can start a 7 day free trial and cancel immediately. There is also a freemium tier at the end if you don't end up converting. We don't normally advertise this because we've been struggling to handle the load and costs of new users, but hopefully as we scale up we'll be able to support a free tier for everyone!
I think the complaint is that you only get told that you require a paid plan AFTER signing up. At least on a brief look on the Play Store page and your website, it does not immediately mention it prominently.
That seems like a very dark pattern and is, honestly, pretty scummy.
This is not a dark pattern, it's just a constraint that the app stores place on the pricing disclosure that is very non-intuitive. You have to mark your app as "free" to download if you charge a recurring subscription fee. You can only mark it as paid if there is a one time fee to download the app.
Our FAQ and pricing pages all list that it is a paid only app. All of our ads explain that it's subscription based. Anyone who asks we're very transparent about it. If there's somewhere else where you think we can list it to make it more clear I'm happy to add it, just not sure where that would be.
What FAQ and pricing pages? Your website makes no mention of pricing at all.
Edit: The "dark" pattern is in the registration flow. It doesn't mention that the app requires a subscription anywhere until after you've created an account. Surely you could add a disclaimer before creating your account? This has nothing to do with the App Store.
Edit 2: I'm not saying you intended to implement a dark pattern. Just perhaps a UX oversight.
Edit 3: The download page would be another great place to put this info, since that's the primary CTA on the home page (there's 4 prominent download buttons).
Looks like we used to have it in the description on the app store along with the FAQ but a team member made the decision to remove it because of complaints about it being inconsistent with the way Apple was localizing pricing to different currencies and regions.
We can't hit people with the paywall before they've registered because we need to assign the trial to their user record. We've tried adding more language during onboarding but no one reads any of it, they just click through.
You're mistaking challenges in building a global app for malicious intent. I left a job paying a lot more to do this because I wanted to help people.
We'll add something back to the FAQ on this, thank you all for pointing it out.
I don't see any mention of the price in the FAQ[0], which I had to guess the url of because it doesn't have a link anywhere on the homepage. Trying to guess the url of the pricing page doesn't yield any results.
They either need to show you ads, charge you for premium for services that used to be free making your free tier functionally useless (looking at you, MFP who gated barcode scanning behind their honestly ludicrously priced subscription), or sell your data, and they often do all three.
The entire industry is like this, and honestly an app that charges one time and fucks off would be ideal but given the amount you'd probably need to charge as a one off (or for major upgrades) most consumers would rather have the slow bleed of $10/mo than $25 one time.
I like the general idea of ongoing revenue, but I want to pay something on par with buying a full version every 3-5 years. Subscription software usually costs much more than that.
Haha, you say this until Apple does a breaking change to the barcode library or Apple Health export and things stop working. Then you probably want them to change some stuff :)
I'm paying for a fitness app subscription that annually is less than 1 month of gym membership. But I had a 7 day trial which got me hooked before I had to sign up for the subscription.
I have a love/hate relationship with qt. It is powerful, generally well-maintained, and I’ve compiled the same app to windows, linux, Mac, and arm, and a specific use case needing JNI on android.
It all just worked.
Their licensing got really goofy for a while, and yocto (which unfortunately I became a “SME” of at work) made cloning and using anything after 5.15.2 very obnoxious. They needed to figure out how to pull a RedHat and get paid support, but this was right around the time electron (at least for a while) rendered native apps as second-class citizens.
The bindings to other languages are neat, and the signal/slot idea is also neat. The whole moc part isn’t great, but I understand why, and it has very rarely caused me any real issues.
Actually it does: Lora the radio protocol has parameters to tune. Usually both sender and receiver needs to match these, so I read this like a method how these could be automatically tuned based on the distance and radio environment.
OpenAi enterprise plan especially says that they do not train their models with your data. It's in the contract agreement and it's also visible on the bottom of every chatgpt prompt window.
It seems like a damned if you do, damned if you don't. How is ChatGPT going to provide relevant answers to company specific prompts if they don't train on your data?
My personal take is that most companies don't have enough data, and not in sufficiently high quality, to be able to use LLMs for company specific tasks.
The model from OpenAI doesn’t need to be directly trained on the company’s data. Instead, they provide a fine-tuning API in a “trusted” environment. Which usually means Microsoft’s “Azure OpenAI” product.
But really, in practice, most applications are using the “RAG” (retrieval augmented generation) approach, and actually doing fine tuning is less common.
> The model from OpenAI doesn’t need to be directly trained on the company’s data
Wouldn't that depend on what you expect it to do? If you just want say copilot, summarize texts or help writing emails then you're probably good. If you want to use ChatGPT to help solve customer issues or debug problems specific to your company, wouldn't you need to feed it your own data? I'm thinking: Help me find the correct subscription to a customer with these parameters, then you'd need to have ChatGPT know your pricing structure.
One idea I've had, from an experience with an ISP, would be to have the LLM tell customer service: Hey, this is an issue similar to what five of your colleagues just dealt with, in the same area, within 30 minutes. You should consider escalating this to a technician. That would require more or less live feedback to the model, or am I misunderstanding how the current AIs would handle that information?
Europe is also a lot smaller network wise.
Hetzner only have to get their traffic to Frankfurt to get connected to practically the whole of Europe. For the US, Ashburn N.Virginia is good but it's still only a single coast.
For text based logs I'm almost entirely sure that just using compression is more than enough. ZFS supports compression natively on block level and it's almost always turned on. Trying to use dedup alongside of compression for syslog most likely will not yield any benefits.
It does work, because the companies will realize that gmail no longer delivers their emails and that they need to change their behavior. Also for example AWS SES (Simple Email Service) will give you clear warnings if it detects that recipients mark their email as spam (it seems that for example gmail delivers this information somehow to SES).
I'd say the opposite instead: we need Kubernetes distributions, just like Linux needs distributions. Nobody wants to build their kernel from scratch and to hand pick various user space programs.
Same for Kubernetes: Distributions which pack everything you need in an opinionated way, so that it's easy to use. Now it's kinda build-your-own-kubernetes at every platform: kubeadm, EKS etc all require you to install various add-on components before you have a fully suitable cluster.
I think the Operator pattern will grow to become exactly what you describe. We're still at the early stage of that, but I can see that a group of operators could become a "distribution", in your example.
