Forums

Just signed up for my beginner account and I'm excited to start making my Flask app! However, before I commit to building my project with PythonAnywhere, there's the issue of pricing that's making me worry a bit. If my app starts becoming popular, I don't like the idea of being forced to upgrade from the $12/month plan to the $99/month plan. Preferably, there would be a few more options between this price range, so I wouldn't have to be pigeonholed into a plan that was either insufficient or superfluous for my website.

Any reassurances/comments available from the PythonAnywhere staff?

+1 on this, a jump of 8 times seems a bit drastic?

Jim

Many, many thanks for posting about this. The Startup plan is a new thing (we soft-launched it on Friday), and we're not sure we have the right balance of features and price for it yet -- feedback is exactly what we need.

One thing we've been discussing in-house is adding a "build your own plan" option, so you could get (say) a plan with just one web app but dozens of workers, or a low-web-traffic plan with lots of storage. We could do a simple version of that really quickly if it's something people want. Is that something you'd be interested in discussing here?

OK, here are some numbers: we could let people create their own custom plans, where:

• Disk/DB space: $0.20 per gig monthly
• Web server workers: $1.25 per month each.
• Custom domains: $0.50 per month each.
• Extra CPU time (the daily quota before your processes are put in the tarpit): $1.80 per CPU hour. This is a daily limit -- that is, a cost of $1.80 gives you one hour of full CPU use every day of the month.

All paying plans would come with unrestricted Internet access, the ability to ssh in, 24 hourly or daily scheduled tasks, and unlimited consoles.

Any thoughts?

@giles

Looks good in general terms, if it's not a pain to implement.

Any chance of more frequent scheduled tasks? (I bet you've been asked before!)

Jim

I would be very hesitant to go with the AWS/Heroku pricing route. A major selling point for PythonAnywhere is simplicity. Sign up, select your Python web framework, and that's it - time start coding. With AWS and Heroku, there's a learning curve, there's jargon, there's information overload you need to deal with first before you can use it. It takes an experienced developer/sys admin to successfully navigate through this level of complexity.

And PythonAnywhere's target customers are not necessarily AWS and Heroku's customers. You guys sell simplicity, not flexibility. The core of your customer base (I'm guessing) lies with the weekend hacker and novice developer crowd. And you don't want to scare away these customers by asking upfront how much storage or how many workers I need. Damned if I know. I'm not even fully clear what a worker is in the first place.

So the way I see it, there's two good options here.

Option A - Offer 5 or so different plans, ranging from around $9 for the entry level plan to $200ish for the enterprise level (helps serve as a price anchor). Best examples of this pricing scheme in action: https://www.linode.com/ and http://www.wufoo.com/signup/ . Consider eliminating the $5/month level plan or finding a middle ground between the $5/month and $12/month level. You're probably losing a good chunk of change here with such a low price point.

Option B - Offer one $9-$15ish/month base plan, but offer upgrades for diskspace, bandwith, memory, and a dedicated IP. Best example of this pricing scheme in action - http://www.webfaction.com.

Either pricing strategy could be successful. A/B testing is the name of the game, though. Some random thoughts about your current pricing table:

• Give concrete examples of what each plan would be appropriate for - "good for running a Flask app with xxxx database queries a day and xxxxx visitors a day", "recommended for small scraping scripts", etc.
• Change the color scheme of the table, a la Wufoo style, to help differentiate each plan
• Testimonials exist for a reason.
• Put the Beginner account to the left of the Hacker account to better explain the feature differences between the free/paid plans.
• Logos of the websites/newspapers you've been featured in at the bottom
• Take the information from the comparison table and put it into the pricing table. Then explain what a worker is, what Dropbox integration entails, how much Bandwith does my website need. Once again, look to Wufoo.
• Get an annual plan once you've solidified your pricing.
• Create a "buying FAQ" to clear up any misconceptions, reduce purchasing anxiety
• Graphically stress the "no-quibble 30 day money back guarantee" on each plan or on the Paypal buttons

Try some of these suggestions out. You can probably double or triple your conversion rate with a few months of A/B testing.

Food for thought: http://www.kalzumeus.com/2012/08/13/doubling-saas-revenue/

Weird, won't let me edit my post above. Giles, just want to clarify that while I don't like using AWS/Heroku's pricing scheme for PythonAnywhere, I think it would be fine for people to be able to buy extra storage space/CPU time on top of a base plan. Just don't make me customize everything upfront.

Maybe something along the lines of $9.99/$19.99/$49.99/$99.99/$199.99 split?

@jgmdavies -- it's definitely been asked before -- I'll add an upvote.

@reinman -- thanks for the detail, that's really useful stuff.

I should have been clear that the custom thing would be an extra option -- so, where right now we have "Hacker - Web dev - Startup" we'd instead have "Hacker - Web dev - Startup - Mix your own plan".

The idea would then be that if we noticed lots of people choosing specific sets of custom features, we could then introduce new plans based on those sets of features. For example, if loads of people wanted something between the $5 and $12 plans and went for a custom one (say, Hacker features but a custom domain and extra web server capacity), we'd be able to see what they wanted and design the new plan's settings around that.

Excellent suggestions for the pricing table -- we recently updated it and I'll see if we can quickly get some of those in there.

Also -- re: it not letting you edit the post, it looks like you somehow managed to create a post as an anonymous user -- I've fixed the post owner so you should be able to edit it now. Had you logged out then come back via the "Try IPython" page or a gist console or something like that?

@giles, I think that'd be a fine start for the pricing table. I'm still a little cautious about that $5/month plan, but I like the idea of using the custom plan to get new data.

As for the logged out page, I have no idea how that happened. I vaguely remember pressing the "Log out" button, coming back to my computer a few minutes later, and clicking "Add post". No biggie, though.

I would appreciate PA to have a "sur-mesure" subscription that allow us to pay what we really need. These times, I really don't need consoles as I schedule all the tasks.

We were thinking that we'd open up scheduled tasks so that any paying customer can create as many of them as they want. Then, if you had 5000 CPU-seconds, you could "spend" them on consoles or on scheduled tasks, whichever suited you.

It would be nice to do something similar for web apps, so that everything came out of the same bucket of CPU time. But I think that wouldn't quite work; scheduled tasks and consoles, I think, make sense if they reset daily -- that is, you get a certain amount of CPU time per day and if you use it all, you get more the next day. Web apps, by contrast, get traffic that spikes up and down unpredictably on a daily basis, so it makes more sense to take an average over the month.

I think it would be nice if Consoles/Tasks had a longer memory. Other than that I don't mind the direction you are going with the tar pit. What do I mean by a longer memory. Suppose a plan earns 40,000 seconds a day, but the user tends to only use their account on the weekends. With no memory, they only get their 80,000 seconds from Saturday & Sunday on the weekend, but now, suppose this same user's account had a two week memory. Thus when their reset comes up the reset adds up to 40,000 seconds, but only if it doesn't take their balance over 14 * the 40,000. That way they could cap at 560,000 seconds. Very nice for them to keep out of the tar pit on the weekends. Then again, the user that is using up all their allotment all the time will be in danger of the tar pit all the time. Just feels like a more balanced and fair way for people who want to use a lot once in a while, but still not enough to add up to the level of abuse.

Interesting idea. So you'd be able to save up your unused CPU seconds, with a maximum "balance"?

Yes, but not save them up so long as to be abused and make the tar pit useless. Just save them up for something under a month max. Very easy to code and also when someone has been away for a few days they don't hit the tar pit in the first 15 minutes of work, so they have nothing to gripe about.

Sounds like a good idea, especially if people have a way of buying more CPU minutes if it turns out that they need more. There may be some subtle reason why we went for a one-day reset, though -- I'll see what the other guys have to say.

« We were thinking that we'd open up scheduled tasks so that any paying customer can create as many of them as they want. Then, if you had 5000 CPU-seconds, you could "spend" them on consoles or on scheduled tasks, whichever suited you. »

That sounds pretty well giles, I strongly agree with that.

PS, off-topic : I would also appreciate having some kind of preview text on PA forum

+1 to OT

@radotranonkala: Great point!! I shouldn't admit how frequently I edit & reedit a post after first adding it to fix something that doesn't format as expected.

Two votes for a preview duly noted, thanks for the suggestion!

Question about stuck Scheduled Tasks, once CPU seconds are counted there as well. Will there be any detection for that or perhaps add a setting to the Scheduled task with a maximum run time before it just gets killed?

For that matter what about other Scheduled Task options like a check box for tar pit meaning this task voluntarily runs in the tar pit, therefore doesn't count against CPU seconds? Of course that isn't exactly how the tar pit works, so maybe something a little more refined. Didn't we once talk about having a queue for Scheduled Tasks versus just running them when their cron time passes? Maybe a check box for the queue and tasks in the queue just get done when they get done. Not sure if there is something useful here or not. Perhaps it will develop more with more input.

We'd not planned anything like that, but I suspect we may have to do it. When we switch on the scheduled task CPU monitoring I'm sure it'll unearth quite a few bits of weirdness like that. Until those have settled down and we've made sure that the system is being fair, we'll obviously be happy to reset tarpit allowances and so on if people are being incorrectly tarpitted. We will be emailing people when they get tarpitted, so hopefully no-one will suddenly unexpectedly discover that things have stopped working and they weren't aware of the problem.

As to what the fair thing to do is... we're kind of torn about "stuck" tasks. Some people use scheduled tasks to keep a constantly-running process, with a (say) hourly task that just makes sure it's still running and starts a new one if not. So we can't really just kill existing instances of the task when it's time to start a new one. On the other hand, it doesn't make sense to have scheduled tasks piling up if they're failing to exit for some reason. I think in the long run, we should provide a separate interface for keeping stuff running, as the scheduled task thing is a bit of a hack. But in the meantime, I'm not sure what the right solution is.

I do like the idea of a voluntary tarpit option for scheduled tasks. The underlying system could support that -- we can arbitrarily tarpit specific processes, it's not entirely a user-specific thing -- but it would be tricky to get right. For example, when your CPU limit resets, a message is broadcast to all machines in the cluster saying "you can un-tarpit this user now". So it would be tricky to put in the hooks so that your voluntarily tarpitted processes didn't get untarpitted then. One for us to think about, perhaps.

I'm late to this but I'd like to +1 for roll-your-own plan. Makes sense. I use Heroku/AWS for other projects that only need the free tier, once you are past that you have to think about every single nibble which is a pain. The plans as described above offer enough flexibility.

Thanks! We're looking at how much work it would be to implement. I don't think it will be that hard, but obviously there might be something non-obvious there.