Dexie Cloud Pricing

[b-straub]

I don't grasp entirely the target audience for a Dexie Cloud driven application/site.
For a webapp the user based pricing doesn't seem to be very suitable, since for such apps usually only a subset of the installed user base is using the database simultaneously. Usually such cloud database pricing models are space/transaction based and post charged (e.g. Firebase, Azure).

Since I develop the .NET wrapper around Dexie, my perspective is driven by Webassembly apps, where an easy to uses cloud database especially with offline/online sync makes a lot of sense.

E.g. would could be the pricing for a shared shopping list app, does such an app even make sense?
Perhaps I miss something and the use case are more B2B apps with a defined number of users.

[dfahlander]

Thanks for bringing it up and sorry for a late reply! A shared shopping list would be a perfect example of an app that could use dexie cloud. I'm primarily trying to target app developers that build apps for end users. The current pricing model aims at making it cheap to get started building an app and grow its users, and also let it be easier for the customer to know the actual cost instead of guessing performance measurements such as CPU usage, network consumption, memory usage, storage etc.

I'm open to all ideas around pricing. The purpose is having a model, an API etc that makes it easy for app developers to launch and succeed with their app. We've been discussing to have a built-in trial support to help app developers get many trial users on board easily without a cost. If building a freemium app where only a few percent of the user will upgrade to a paid version of the app, it would be costly having to pay for all the users that aren't paying. For that reason, one of the features that could be included in a paid version would naturally be being able to sync and share data. A shared shopping list would be a perfect example - when the trial ends - they'll be able to keep using their app, edit and add items, but it would simply stop syncing until they upgrade. And the upgrade has to be done between end user and customer - so that customer can call some API in dexie cloud to resume the user's sync when user has paid to customer - and the user would start being counted in the purchase from Dexie Cloud to customer.

There's also always the on-prem license option with no limits of number of users.

[dfahlander]

The idea I have been looking at is to provide a purchase solution for the end user (optinally available to redirect to for devs that don't want to provide their own solution), but let the dev set the price and my company gets a fair amount but the rest goes to the dev.

With end-user payment through Dexie Cloud, I could simply redirect the user to your payment process, and since for most users something like five production seats might be enough, you could offer something like an annual subscription at a reasonable price. Such a solution may require some changes to the underlying authentication model, as the licence will be tied to a user's dedicated realm and define how many realm members they can synchronise with.

My guess would rather be that most users would buy single seats for themselves. Some small businesses might want to buy a few seats though - it all depends on the type of app their subscribing to. I strongly believe the app should be in focus and not sell some kind of generic storage - that might work if we were Google or Microsoft - but the particular end-user would only be interested in the app thei're looking at and buy a subscription for that.

[b-straub]

The idea I have been looking at is to provide a purchase solution for the end user (optinally available to redirect to for devs that don't want to provide their own solution), but let the dev set the price and my company gets a fair amount but the rest goes to the dev.

Great idea, for FOSS the devs amount should go down to zero. The purchase will then be just for providing the cloud infrastructure and maintenance.

My guess would rather be that most users would buy single seats for themselves.

One seat would allow synchronisation between multiple devices, right? Still having FOSS in mind here as well. Some solutions will require sharing a realm with a small group of people like family or friends.

[dfahlander]

One seat would allow synchronisation between multiple devices, right?

Yes!

Still having FOSS in mind here as well. Some solutions will require sharing a realm with a small group of people like family or friends.

I see. Makes sense.

[b-straub]

I strongly believe the app should be in focus and not sell some kind of generic storage

Totally agree, but let's assume I want to make the ultimate shopping list app (FOSS or paid) since I'm not happy with the current solutions usability. Sure I want to share some of the shopping lists with my family or even sometimes with friends (e.g. for a mutual friend's birthday party).

So how this would work?

Buying three production seats for the family for daily usage and adding the friends as eval users for the birthday case. Eval doesn't seem the right choice here.

[dfahlander]

You'd probably share the link that leads to your list in the app to your friends - they sign-in and start their free evaluation period. If this is a short usage (single day or a few days) they might only consume a part of their evaluation and may continue like this for your next birthday until the eval days reaches zero. They would probably buy a subscription after becoming a recurring user for a while. Or they change to another app at that point. It would all depend on how great the app would be. The point is: already with the current model, it is easy to share apps and let anyone try it and use it for real until knowing if they're willing to continue using the app and pay for it.