Sorry about that. I'll try to make that clearer. We have an FAQ item on teh bottom of the page.
The pricing is per project (per app). You pay $250, and you get one year of updates and then use it forever.
The license is a Perpetual Fallback License. When you stop paying for a subscription, you will still be able to keep and use the latest version of Avo at the point in time when the subscription ended but you will loose the ability to update to a newer version.
Regarding locking and doing transactions, it does not support that, but that's a very good idea and not that difficult to add in the near-future. Ideally to let the developer specify what kind of locking strategies to use.
The "one year of updates" thing is kind of confusing. What if an app has a longer lifetime than that? Can you no longer get updates to Avo? What about bugs and security updates?
I think you're over-complicating the pricing. Why not just say it's $250 per project per year? You can still keep the fallback option and explain it in your FAQ. It would be more immediately understandable this way imo.
I tried that and the question that popped up was "what if I don't pay anymore? will I not be able to use it then?". It kind of turned people away, and that's why I change the copy.
If an app has a longer lifetime than a year, and I hope it does, then you'd have to resume the subscription to get the updates (bugs and security). It's the way the perpetual-fallback license works. There are plenty of products (table plus, jumpstart rails) and large companies (jetbrains) that practice this model. I wish there was an easier way of shipping those updates without a subscription.
I think it’s a mistake to optimize for people whose focus is what happens if they stop paying you. They’re unlikely to pay in the first place and are more likely to be difficult customers even if they do.
Customers who get value out of your product will want to pay and keep paying and be sure they’re not going to miss important updates if they forget to renew in a year. These are the customers to focus on imo.
People are happy to pay subscriptions for software they get continuing value from. There’s no need to reinvent the wheel on this.
This is the approach JetBrains takes with their IDE suite and it's the best of both worlds in my opinion. It takes most of the risk out of the decision-making process. To date I've kept my subscription active, but I probably wouldn't have signed up if I didn't have a fallback option.
Maybe this is an esoteric case, but I have a project from a previously operating business (TechStars Boston 2010). Every now and then I think I'd like to take a nice stroll down memory lane. And then I remember I have one component that was an annual SaaS that I no longer have an expensive license for, so the thing won't boot. And I don't have the wherewithal to invest the time to replace it. It's extremely unlikely I'll ever adopt something similar in future projects, personal or otherwise.
I get "continuing value" from all sorts of things I'd never want a subscription for. If you're confident in your product's ability to innovate and continue to add value, you shouldn't worry about attrition. Providing a fallback option makes it clear to me that you have that confidence and that makes a huge difference during a purchase decision.
Just to be clear, I’m not arguing that he should remove the fallback option, just that a subscription should be the default. I agree the fallback is a good thing that reduces lock-in/shutdown risk. But that benefit can still be offered alongside a yearly subscription.
I mostly agree with you, but that's on more "traditional" SaaS products. When it's a service. This is more of a product.
There are developers and agencies that buy Avo, build something for a customer and then transfer the license to them. The customer might not even know that the agency bought something. They might not want to pay something ongoing.
Yes, one could make the case that "hey, you pay hosting ongoing after the project is delivered, why not pay the admin framework?" and that's fair, but I just don't know if we're at that point yet. I'd love it if Avo would bring us closer to that point.
I see your point, but I think it’s just a framing issue. It’s great to have an option for people who are concerned about this, but not at the expense of confusing customers who just want to pay you and keep paying you for your thing, and also killing your year 2 retention by making it opt-in instead of a normal subscription.
Looking at jumpstart rails, they seem to be doing exactly what I’m suggesting. It’s a simple per project per year price, but then in their FAQ they explain that you stop getting updates if you stop paying.
On the agencies point, yeah I think it’s normal for agencies to sign a client up for a bunch of services they need to build the project. You’ll just be one more on the list.
Well... Avo's pricing is exacty like Jumpstart's (except the $750 for unlimited). So pay $250, get Avo (or Jumpstart) with a year of updates. When you stop paying, you keep what you have until that point and no more updates. Isn't that the same? Am I missing something?
Also, you do make a point regarding agencies "sign a client up for a bunch of services". I'll try and experiment with that. Thanks for the nudge!
Right, that’s exactly my point! Jumpstart has basically the same pricing/licensing but doesn’t frame it in a confusing way.
At first glance, it’s just a yearly subscription per project. Simple and standard. Everyone understands it.
If I’m concerned about what happens if I stop paying for jumpstart, I can find that information, but it’s not emphasized at the top like it is on your pricing page. And the yearly subscription is the default, not something I have to opt into again every year.
Most customers are just going to sign up for a yearly subscription and never look back. It’s better for the customer and for jumpstart.
Also at what is the frameworks strategie on locking doing transactions in the database.