The website is nice and clean, well done! The idea is clear for a developer-type of mind.
Just a few specific remarks:
* smallest billing period is 1 month so I'd change jobs/day quota to jobs/month. Daily quota for a monthly plan is somewhat confusing and looks rather restrictive if it doesn't roll over to the next day.
* I'd drop yearly plan and "Servers" limit to keep things clear and simple. If needed, would add "contact if you need special arrangements (self-hosted, yearly plan etc)".
* To become easier to find by search, I'd find main use-cases why someone would use this template API for bulk-pdf conversion in the first place and use these use-cases for the selling, not focusing on the "template" and "API".
If it turns out that most of the users are using it for just one specific use-case then I'd focus on these and go extra mile to make it even more useful for that specific user-group.
The risk of focusing on actual use-case is that right now the site is very easy to understand, if rewriting it to tailor for use-cases then dev-minded surfer doesn't grasp what goes on.
I'd see companies use this service to generate invoices for small businesses or SaaS providers (running monthly the database query and feeding it to your API and storing the invoice in S3); tickets; vouchers; event nametags; customizing a presentation and document that is sent to the customers' user; where else?
EDIT: Ahh yes, and when logged in, please provide a way to see pricing and a way to convert to a paid account! :)
Let me just add a vote for creating a set of use cases to demonstrate the potential use of the service. I think it would go a long way to helping non-technical users understand the value. It could just be me but if a developer has to get involved then the value proposition to me is much smaller as I'd just use dompdf, fpdf, or some similar library.
Comments
The website is nice and clean, well done! The idea is clear for a developer-type of mind.
Just a few specific remarks:
* smallest billing period is 1 month so I'd change jobs/day quota to jobs/month. Daily quota for a monthly plan is somewhat confusing and looks rather restrictive if it doesn't roll over to the next day.
* I'd drop yearly plan and "Servers" limit to keep things clear and simple. If needed, would add "contact if you need special arrangements (self-hosted, yearly plan etc)".
* To become easier to find by search, I'd find main use-cases why someone would use this template API for bulk-pdf conversion in the first place and use these use-cases for the selling, not focusing on the "template" and "API".
If it turns out that most of the users are using it for just one specific use-case then I'd focus on these and go extra mile to make it even more useful for that specific user-group.
The risk of focusing on actual use-case is that right now the site is very easy to understand, if rewriting it to tailor for use-cases then dev-minded surfer doesn't grasp what goes on.
I'd see companies use this service to generate invoices for small businesses or SaaS providers (running monthly the database query and feeding it to your API and storing the invoice in S3); tickets; vouchers; event nametags; customizing a presentation and document that is sent to the customers' user; where else?
EDIT: Ahh yes, and when logged in, please provide a way to see pricing and a way to convert to a paid account! :)
The advice about writing down specific use cases to come up more often during search is brilliant. I have no idea why I did not think of this myself.
This will be among the first things I am going to implement.
Let me just add a vote for creating a set of use cases to demonstrate the potential use of the service. I think it would go a long way to helping non-technical users understand the value. It could just be me but if a developer has to get involved then the value proposition to me is much smaller as I'd just use dompdf, fpdf, or some similar library.