Wow, this is like Aesop’s Fables time! Everybody has a different idea about the elephant!
Did you write pages but mean sites? My current thoughts about the pricing relate to sites, not pages. I doubt that a page limit would be a good idea, particularly when it is so painfully obvious that once you have a system like this running, you can have as many pages as you like within a site – there’s literally no incremental costs involved.
In my own practice, I often use hosted services for my clients. I will have them sign up for hosting, S3 storage, secure certificates, whatever else their project may need – video transcoding or similar – on their own credit card. They forward the “welcome” letter to me with the credentials, and I get to work building the final system for them. They understand that there’s no (practical) way to duplicate what these services do, and that they need the service.
In this case, you could pitch this to your clients as follows:
- I could build you a site, and when you want changes, you can come back to me and pay me monthly/as needed to make those changes.
- I could build you a site, and design the template for a blog (Wordpress) and give you the keys to the blog. You could write blog articles, but you would need to come back to me for any changes to the rest of the site.
- I could build you a site, and when you want to make changes, you could go to this page, log in, and make them yourself. As many changes as you want, whenever you want, for one low monthly fee (along with your hosting).
If you had a bunch of clients that all needed variations on that third option, then you could sign up for the Gold or Platinum version yourself, and then charge each of your clients the full rate of the Silver plan. You would make beaucoup markup every month, and I bet you’d sleep like a baby.
Anyway, back to the idea of the download-and-install Inlay: I pretty much abandoned that approach when I started to see the results of my testing program. 1 in 4 people who tried it could not make it run on their server under any circumstances. Either a PHP or MySQL mismatch, or an Apache configuration nightmare. Those are not the sort of odds that inspire confidence, especially since my tester pool was selected by me for their relative geekiness. I was more interested in testing the optimal user rather than the average. The code I wrote is still on GitHub, and if I find the time, I may release it for community study and use as open source. The idea is sound, but the cost of supporting this execution would have outstripped any income I could have made from it, particularly if you consider it to be a one-time purchase.
Inlay as it stands now (current feature branch) is a Rails application, and it’s so far outside of the realm for someone to just “download and install it” that I wouldn’t ever consider selling it in that form. Already, it does things that the PHP version never did, and couldn’t be made to do without serious re-engineering. The Rails ecosystem is so far evolved beyond what exists in PHP that it means I could add features for years without having to write any of them from scratch.
Subscription software is the future, and brings with it a number of interesting power dynamics. I am painfully aware of this, as Adobe have “converted” me from the old world to the new. I am still hopeful that another application may come along to replace Illustrator for me (no, Sketch isn’t it, not yet). When you subscribe to a service like this, you pay monthly, and can cancel any time. That puts an onus on the provider to keep delivering value, not to stagnate and die. It also spreads the risk of new versions around, rather than concentrating it on the author. Think about what Adobe had to do prior to the CC versions. They would work for years on some new package of features, hope that they were enticing enough to the public, spend millions promoting them to the world, and hope that enough users bought upgrades to justify that expense. And worry that people wouldn’t take the upgrade, and have to support the older version(s) for a very long time.
Software as a Service means that everyone gets the latest version as soon as it’s ready. The developer has a steady stream of income to offset their investment going forward (and to pay the carrying costs of the infrastructure to support hose users). It’s a decent trade-off, once you get your head around that.
Finally, because this is a month-to-month (not long-term) relationship, I am making steps early (now) to make the exit as painless as possible. My goal is for a user to be able to subscribe to the service, use it, decide they’re done making changes to their site, and be able to exit the service without any pain (except that they will lose the ability to edit those changes they have made so far). The site will not stop working, and their content will not be held hostage.
My wife’s practice management software works in the diametrically opposed mode – if she ever stops paying the annual “support” fee, her entire patient database and all electronic medical records become read-only and insanely difficult to export in any usable format. To my mind, this is just one step away from those gentlemen who come around to your shop and say, “Nice place you got here. Be a real pity if it were to burn down…”
Walter
On Jul 15, 2014, at 6:42 AM, Thomas Kimmich wrote:
- Silver: The core - Single page license 25$
- Gold: The core - 10 page license 50$
- Platinum: The core - unlimited pages 99$
Future Features extra.
Cheers
Thomas
offtopic mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options
offtopic mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options