This commit is contained in:
@@ -240,6 +240,13 @@ HVAC 150
|
||||
|
||||
#### SUBSCRIPTION / SAAS
|
||||
|
||||
##### Must be tied to active users
|
||||
|
||||
That means all users who login including customers
|
||||
|
||||
Customers would be low usage though you can imagine so they could be much cheaper or let's say you get xx customer logins and $xx for a block of a big number of additional
|
||||
Like 100 customer logins included, 20 bucks a month for additional blocks of 100 more
|
||||
|
||||
So it's clear looking over things that there's a cost for a droplet and adding x more users doesn't really add to that for us so if a $5 droplet works for a single user up to let's say at least 10 users, just speculation, we make way more money off the 10 user. The price for a single user must be increased to accomodate that or...we host more than one site on a single droplet to offset the cost, but charge enough to move them up to a higher level without needing to increase the charges to compensate.
|
||||
|
||||
so pricing should be the highest normal droplet we can use
|
||||
@@ -253,11 +260,13 @@ So let's imagine a different scenario, let's say there are .75 users for every s
|
||||
|
||||
WAYS TO FIGURE
|
||||
|
||||
Assumption, average server cost will be 20/month per customer (hopefully more like 7 but in some cases 21 or worst case 68)
|
||||
|
||||
WHAT IF we just charge double the perpetual maint rate?
|
||||
|
||||
Maybe double the perpetual maint price so 16.66 rounded up to 17 per month per user?
|
||||
|
||||
WHAT IF we just charge $35/mo (yearly 12.5% discount and the assumed price everyone would pay) $40/mo (monthly) about triple the maint price
|
||||
**WHAT IF triple maint** we just charge $35/mo (yearly 12.5% discount and the assumed price everyone would pay) $40/mo (monthly) about triple the maint price
|
||||
|
||||
so for one user our profit if they paid yearly would be assuming a 7 dollar server 35-7=336 dollars per year, maybe not worth it so minimum 2??
|
||||
two user 70/mo-7=63\*12=756/year, that should be less than 1 hour of my time average per month to be worthwhile, like seconds at most
|
||||
@@ -266,8 +275,17 @@ two user 70/mo-7=63\*12=756/year, that should be less than 1 hour of my time ave
|
||||
|
||||
10 user would be 350/mo-7\*12=4116/year
|
||||
|
||||
So going by the wild assed assumption that our current subscriber levels all went to SAAS the profit could be:
|
||||
1 user->2user so assume we keep only half of them, there are 30 singles so 15*70=1050-15*7\*12=
|
||||
**WHAT If quadruple maint (TOO HIGH)?** I have to do a lot of coding to keep retaining so it needs to be worth our while so 4 times the maint rate? (66.66, round to 65) 75/mo
|
||||
1 user 65-7=58\*12=696/year
|
||||
5 user would be =3480, ulp! that seems high, good for us though!
|
||||
10 user $6960
|
||||
|
||||
##### UNKNOWNS TO FIGURE OUT
|
||||
|
||||
Domain work (pricing and practicalities)
|
||||
Email (pricing and practicalities, like do we do this under our domain or)
|
||||
Storage practicalities (pricing just a factor)
|
||||
Server sizing
|
||||
|
||||
###### Server costs
|
||||
|
||||
@@ -291,11 +309,14 @@ Maybe the way to look at this is a basic price with options that directly corres
|
||||
##### Add-ons upgrades
|
||||
|
||||
- STORAGE: So we assume a cheap ass droplet and offer add-on's like more storage attachment space for XX / mo which is really just the digitalocean pricing plus a premium overhead for contingencies if they want it
|
||||
- ATTACHMENTS: we need an add-on for larger attachers, i.e. normal one is considered lite on attachments, no more than 10gb total or somethign as a rule of thumb, if they have greater needs then it's an add-on priced as per digitalocean with wiggle room on top and profit
|
||||
also needs to be their backup volume too, i.e. all file storage except db
|
||||
- RAM / CPU: maybe we offer basic server but they can upgrade to levels for additional per month
|
||||
- BACKUP: self is free vs we do is whatever digitalocean charges plus a premium
|
||||
- Email, if they don't bring their own account we provide at a cost / sendgrid or whatever (I suspect people expect this to be included if turnkey from a phone or something)
|
||||
- Anything we get billed extra for, as it stands we don't care how powerful they need, ayanova supports it, but we don't pay for it, they do.
|
||||
- So, maybe the way to go is base everything off a tiny or next to tiny server and anything else they can pay for as an upgrade.
|
||||
- MIGRATION, we migrate from v7 for them for a flat fee, it's potentially hours of work 200 dollars?, or they can do it themselves
|
||||
|
||||
### Comparatives
|
||||
|
||||
|
||||
@@ -25,6 +25,8 @@ todo: License agreement changes for SAAS customers, this is huge and I hadn't th
|
||||
Needs a disclaimer about the right to refuse service if becomes too high usage i.e. subject to usage limitations to cover our ass and check with D.O. how to clamp that from going into expensive territory for us?
|
||||
We also need to mention we will size their servers to adequate work load or whatever meaning we will put them on the smallest cost server that will sustain their needs.
|
||||
|
||||
todo: SAAS gaming, once have idea of plans and add-ons, need to test it out on servers and see what's what and how it would work in practice
|
||||
i.e. storage on block storage, backup practical things etc
|
||||
|
||||
todo: ROCKFISH different license key signature if it's a SAAS license
|
||||
this solves a lot of problems, effectively it's unlicensed if they move their data to their own hardware without a key
|
||||
@@ -40,9 +42,10 @@ todo: RENTAL terminology needs to change to "SUBSCRIPTION" in rockfish and in cl
|
||||
todo: SUBSCRIPTION should only refer to month to month SAAS feature / plan. Support and upgrades should be referred to as Maintenance or Support and upgrades without the word "subscription"
|
||||
TODO: above changes at SHAREIT with the product descriptions as well so no confusion
|
||||
|
||||
|
||||
todo: if SAAS needs to do some things differently:
|
||||
if it helps, consider a different build flag since SAAS is like an internal build for us
|
||||
SERVER - count total active users towards license not techs only
|
||||
SERVER - Count total active users AND SEPARATELY total active Customer login users towards license not techs only
|
||||
SERVER - different signature for license keys
|
||||
ROCKFISH - different signature when SAAS key
|
||||
SERVER - some routes not enabled around licensing, operations etc
|
||||
@@ -60,9 +63,14 @@ todo: if SAAS needs to do some things differently:
|
||||
SERVER - hide any info about the droplet technical stuff like ram and ops stuff, we don't want them to have an idea how much memory they can have, or do we?
|
||||
maybe it's a plust because we can say you get a maximum storage for attachments of XXGb based on droplet size and it's an add-on to go with a bigger server??
|
||||
Because some people need it and will pay for it if it's offered.
|
||||
YES hide all ops but for ops users or us whatever we need though I guess we can just api our own UI for it
|
||||
They should have an easy way to see storage
|
||||
SERVER - how to cap bandwidth, storage, whatever we get billed extra for from d.o.
|
||||
YES Needs to cap and not allow attachments and warn when getting low on disk space, we're probably ok with db size and can just eat it, who will even get near the capacity for that, it's the attachments that are the bugger
|
||||
CLIENT - NEEDs to report that a new version was installed to the user with link to changes when we publish a new version so they can be made aware
|
||||
EMAIL - research how to send emails with a reliable provider i.e. sendgrid or alike and what the costs and add-on price for that would be.
|
||||
SERVER / CLIENT - BACKUP we can't have them frigging around with it and fucking it up, if we're in charge we need to set the routine and locations etc, if they are in charge need to ensure it's not making too many backups somehow
|
||||
BACKUP screen should show capacity available in destination backup location
|
||||
|
||||
todo: each droplet for SAAS would need it's own ssh key and password to avoid eggs in one basket security scenario
|
||||
also would need to securely store the passwords somewhere really really fucking secure like offline in a special keypass only accessible from certain hardware maybe with a digital key or something I dont' know
|
||||
|
||||
@@ -7,7 +7,7 @@ theme:
|
||||
site_name: AyaNova manual
|
||||
site_dir: '../../../server/AyaNova/wwwroot/docs'
|
||||
strict: true
|
||||
copyright: Copyright © 2022 Ground Zero Tech-Works Inc. REV-2022-08-08
|
||||
copyright: Copyright © 2022 Ground Zero Tech-Works Inc. REV-2022-08-12
|
||||
extra:
|
||||
generator: false
|
||||
# Extensions
|
||||
|
||||
Reference in New Issue
Block a user