Then they changed it to browser based, subscription only, Chrome only. The whole thing becomes read-only the moment your credit card stops drip-feeding the subscription.
When you poke around in these tools on the weekend, the subscription model falls flat. Being billed for "time" that happens to fall between my use of these products, is a bizarre way to charge customers for software. I get that if I rented a lawnmower, I'm paying for every day I have that mower because other customers want that same mower.
Construct 2 was pay once, but we found after a few years sales really plateaued. Going to SaaS was a difficult transition for us, but it's worked out well and we now see year on year growth which gives us a lot more breathing room.
I think it's important to also recognise that pay once software just doesn't work as a model for a lot of countries around the world. As an example, for Construct 3 we charge the equivalent of ~$12 USD per year in Malawi which makes it a very affordable option, whereas a one-off price would have to be roughly quadruple that for it to be economical for us, and would likely put it out of reach of a lot of people who otherwise may of paid annually for it.
SaaS puts more onus on us to cater for our current paying customers, before with pay once our focus was weighted on acquiring new customers. To what extent this actually plays out is kind of tricky to put your finger on especially from where I'm sitting but there is certainly an element of this in our work.
I'm not going to pretend that SaaS is suitable for everyone and every product and I understand why people are adverse, but for us it's worked well and a lot of noisy predictions from some of our customer base about this being our downfall never played out. The transition to pay once to SaaS was a vulnerable time for our business and a very interesting one at that.
Pay once still works. You could have increased the price to $500 or something. It would then take 3+ years of subscription pricing to equal one pay-once amount. Many users would opt for subscription anyway in that case.
> noisy predictions from some of our customer base
When customers make noises about the pricing, you have the choice to stand your ground and fight the war on pricing. Or you could meet them half way. But you stuck to your guns, and so did I when I jumped ship back when the newly released Construct 3 was indeed Chrome only at the time. I never made noises on the forums about it because I was fairly new to Construct 2. I just left quietly.
It could also reflect badly on us if customers on older versions are demoing the product to other potential users when they are many release cycles behind the latest version. There's a myriad of benefits of just having all customers on the same version. To go down the maintenance plan route for us would be a mistake.
Generally propositions from customers for different or more exotic pricing methods over what we've gone with tend to involve a lot more complexity to ultimately allow people to buy it for less. The model we've got is working well, and we don't see any advantage to changing it right now.
> I never made noises on the forums about it because I was fairly new to Construct 2. I just left quietly.
Which is fine, but we're a much more successful company than we ever were with Construct 2, largely because of the direction we went with pricing. We accept it's not for everyone. I think looking back over our history we've gone from Open Source to Pay Once to SaaS. When you go through these changes you're going to lose customers who were attracted to your original payment model, this is just a reality we have to accept.
That was one of the most frustrating things about using construct 2. The archetype was effectively arbitrarily designated as the "first instance of that object on the first layout of the project", so if you spawned new instances they would be preassigned those settings. It was very non-obvious and led to people having to build helper functions that would spawn new instances with the desired default settings.