-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Celest Store #45
Comments
Hey @marcglasberg, what a cool idea! I think this makes a lot of sense, and in fact, I had never considered that the generation of a client library could be an out-of-the-box means of distribution in these cases 😄 A few things we would need to figure out would be:
I really love this idea because one of our driving principles has always been to build Celest in such a way that one could eventually rebuild Celest in Celest 😄 this is a great exposition to some of those steps needed. |
Hey, maybe we could discuss these questions and my particular use case over Zoom at some point? As I can't discuss the details of my service here. |
Absolutely. Door's always open! https://cal.com/celest-dev/dillon |
Thanks! I'm busy until March 4, but then I'll set up a meeting in your calendar. |
I want to be able to provide SaaS for companies that use Celest in their apps, and charge for them. When publishing my Saas with
celest deploy
in the store, I'd provide ayaml
file (or better yet, Dart code) to create a store page in the Celest website, much likepub.dev
does for Flutter.I'd have 4 pieces of software:
<name>_frontend
in pub.dev: A package projects can include inmy_app/pubspec.yaml
<name>_backend
in pub.dev: A package projects can include inmy_app/celest/pubspec.yaml
Example
For example, suppose I'm Harry Potter and I want to provide a SaaS that allows apps that use Celest to have magic features in their apps. In this example I'd publish:
celest_magic_frontend
in pub.devcelest_magic_backend
in pub.devA Celest service that gets requests from those packages, does magic in the server, and sends the magic to the frontend package, so that it's displayed to the user in the app. Note: The companies that added my SaaS to their apps DO NOT have access to the source code of my Celest service. They simply use the service.
The Celest database must have different access settings depending on the project: Only I have access, or I can choose to let the client company to have access too.
Pricing
Celest wouldn't charge anything for the store listing, but it would make money because the Celest is being used by the service and the Celest database.
Celest would charge the client company directly, not the SaaS service provider.
Celest would add an extra on top of its bill to the client company, to pay the SaaS service provider. That extra would be chosen by the SaaS service provider, and it could be a combination of: (i) a fixed monthly value; (ii) a % of the regular bill the client is paying Celest. For example, I could choose to be paid $5 plus 10% over Celest's normal cost. If the Celest regular bill would be, say $150 in a month, Celest would charge the client $150 + $5 + 0.1 * $150 = $150 + $5 + $15 = $170. I'd get $20.
Rules
It would be great if Celest could provide rules for pub.dev packages that are in the Celest store. For example, how should I name my packages:
celest_magic_frontend
andcelest_magic_backend
celest_magic_flutter
andcelest_magic_server
magic_for_celest_frontend
andmagic_for_celest_backend
Should there be a rule like this?: First thing you must say in the package docs in pub.dev is that it's a third-party service not provided by Celest, and that Celest is not responsible for anything, damages, etc etc; and then link to the Celest store.
Note
This is not hypothetical. I already have a service that I want to provide for Celest client companies.
The text was updated successfully, but these errors were encountered: