Have you submitted to Product Hunt yet?
Not yet! With the feedbacks I just received, I want to improve the API before posting on PH.
Show HN: Convier.me – A Calendar Service for Developers
31–40 of 87 posts
Re: Show HN: Convier.me – A Calendar Service for Developers
#323 attendee max/request seems low for $9/month per user.
Re: Show HN: Convier.me – A Calendar Service for Developers
#33You may not want to offer a free version. Freeloaders don't convert and they become a support burden whether or not you offer support to them. Once you want to shut off the free version, which you will, you're going to make those people who used your thing and didn't value it enough to pay you for it mad. They wont convert, they'll just get toxic, because they'll feel entitled to your free service. A free option isn'…
I agree with this advice for SaaS in general, but there are exceptions. Eg Typeform and Calendly and Dropbox all grew virally through their free tier. Given that this product is a bit similar to Calendly, perhaps a similar effect can be achieved.
Re: Show HN: Convier.me – A Calendar Service for Developers
#34Earlier quoted context omitted.
This is in response to toxic users. But supporting freeloaders costs money. I’m saying weigh your conversions. Your comment suggests to discount freeloaders entirely.
They're going to be toxic to you, in emails and on your support chat or @'ing you. They're going to drain your energy and make you upset. Nothing good will come from it.
Basically any popular SaaS in the wild today would disagree with your "Nothing good will come from it" comment as 99% of them offer some sort of free plan.
It's really hard to start a service from 0 and get users to join the platform when it's new. Imagine then that there is no way for users to try out the platform before subscribing to it, uptake will be even lower.
You don't have to reply to every chat and communication channel, especially if it's clear that you've already tried to help the user and it's not enough for them. Ignoring is a powerful tool many forget.
Re: Show HN: Convier.me – A Calendar Service for Developers
#35I've built a free add to calendar link generator tool, and late added an API. Costs me about 30c a month on serverless :) https://calndr.link Feel free to ask any questions.
This looks super useful - nice job!
Re: Show HN: Convier.me – A Calendar Service for Developers
#36Where will this be useful? I don't understand the use case
That’s exactly what I was thinking.
My first reaction was ‘this sounds like it might be useful’ but I’ve read the copy and I still don’t fully grok where I would use it effectively.
Having the curl example is good, but I feel like a few example workflow diagrams that show some cool things you build with it would be useful.
Re: Show HN: Convier.me – A Calendar Service for Developers
#37Any chance you could convert pricing to $X per 1000 requests? My previous company needed something like this (we ended up building it our selves at a whooping cost) but our needs were 50k+/mo of calendar invites.
Re: Show HN: Convier.me – A Calendar Service for Developers
#38Nice idea, but seems to lack timezone awareness, which puts me off completely. Maybe that's being developed, but the American date format with no timezone being described as "English textual" (say what?!) seems to be ignoring all the standards for date and time (eg. RFC3339[1]), yet other parts of the docs clearly show awareness of RFCs! If you're pushing events to people, presumably you know exactly when they're goi…
Yes, I don't understand american/English dates and time. I don't know when "04/06/2019 09:00 PM" is. Is it April or June? 0900 or 2100? Let me send an ISO8601 time as all other APIs accept.
Re: Show HN: Convier.me – A Calendar Service for Developers
#39Nice idea, but seems to lack timezone awareness, which puts me off completely. Maybe that's being developed, but the American date format with no timezone being described as "English textual" (say what?!) seems to be ignoring all the standards for date and time (eg. RFC3339[1]), yet other parts of the docs clearly show awareness of RFCs! If you're pushing events to people, presumably you know exactly when they're goi…
Yes, I don't understand american/English dates and time. I don't know when "04/06/2019 09:00 PM" is. Is it April or June? 0900 or 2100? Let me send an ISO8601 time as all other APIs accept.
"09:00 PM" almost universally (is there any case or format or app that does it differently?) means 21:00 in 24-hour clock format. Not 09:00 (in 24-hour clock).
Re: Show HN: Convier.me – A Calendar Service for Developers
#40Nice idea, but seems to lack timezone awareness, which puts me off completely. Maybe that's being developed, but the American date format with no timezone being described as "English textual" (say what?!) seems to be ignoring all the standards for date and time (eg. RFC3339[1]), yet other parts of the docs clearly show awareness of RFCs! If you're pushing events to people, presumably you know exactly when they're goi…
Yes, I don't understand american/English dates and time. I don't know when "04/06/2019 09:00 PM" is. Is it April or June? 0900 or 2100? Let me send an ISO8601 time as all other APIs accept.
AM / PM clears up the 0900 vs 2100 ambiguity, but agreed re; American date formats.