Also the fact that cost is not easy to calculate creates a barrier to understanding what the cost would be, which less-motivated people may not bother overcoming.
What made you choose this model?
Ultimately, I don't know who is going to use the platform. It's created in a way that it can be just as useful for a random person who wants to make a few invoices per month, someone who wants to make 10,000 payslips every 2 weeks, and someone who wants to hook it up to their product to pump in data and receive a link to a PDF via the API. The first person would not pay for a subscription, it's just not worth it at their usage level. The second has burst bulk usage which should be discounted. The third has some level of sustained usage over time.
Those 3 use cases are covered by the 7 days, 30 days and 2 years pricing structures. If you're a casual user, pay a bit more and don't worry about expiration. If you're a bulk user, you get a discount. Everyone else can treat it like a subscription and get the best of both worlds.
I looked to websites that do similar things for ideas, and the closest I could come up with was sites like ShutterStock which also have a credit system where the more you buy the cheaper it is. I believe their credits expire after a fixed period too, but you don't get a discount for how long which is a bit more specific to my product.
Thanks for the feedback! How would you prefer to see a service like this priced that wouldn't cause price anxiety? I'd love to hear different ideas since this can be changed.
If something seems like a dark pattern, it is. I hate to be the bearer of bad news, but the ultimate judge of what is dark/what's not is the end user, and sending them a leaflet about how good it is doesn't do much to assuage their fears. I understand your motivations here, and sympathize with you as a developer: but as a user, I couldn't justify integrating this into my workflow.
I'm not strictly opposed to the idea of self-hosting, although it would be far easier to pull out the API + queue + worker elements of the product rather than allowing self-hosting the whole thing. That way you self-host the production side and the document data doesn't leave your servers (which is likely to be a big deal for many businesses), but your templates and API calls are compatible with the online version of Creodocs. I'll try to get some more feedback on the pricing model and think about it myself, since it sounds like it's a bad one now. Thanks again for your feedback!
He is a well known figure in the TeX community and has created a (open-source [2]/self-hostable) document creation solution on top of LuaTeX.
You can simply run that from the command-line and integrate it in your workflow but it also comes with a server integration that provides you with a REST API.
Admittedly there is some kind of learning curve (even for LaTeX literate people as he is using an XML/HTML abstraction layer on top of it) - but that also keeps it interesting for users who have never played mich with any TeX-language prior to that date.
[1]: https://www.speedata.de/en/ [2]: https://github.com/speedata/publisher