This could be an extremely interesting legal argument, but I suppose the language used requires a request in 'writing' of some sort, which I suppose HTTP requests would fail.
> This could be an extremely interesting legal argument, but I suppose the language used requires a request in 'writing' of some sort, which I suppose HTTP requests would fail.
Are emails not considered communications "in writing"?
how about a request form that ostensibly takes an email address and a name, and an optional text field and then automates the process of sending the paper (or a hidden (unique) link to that paper) to that email address. it need not store those details anywhere, except that it optionally sends an email to the author (if there is a message). the only concern is spam.
Or better... have an email address like papers@authorname.com which receives requests with the title of the paper in the subject line, and a piece of software then receives the request, waits for a random amount of time (anywhere between 10 mins to a couple hours), and then sends the paper to the requester.
It would seem that the author personally received the email and replied with an attachment as a "professional courtesy", while completely automating the process in the background.
that would be to hard to use. the idea is to make the experience as similar as possible to clicking a link to download without making the document directly available for download, but make it look like a personal request that could be handled manually. by submitting a form, that is achieved. the form ensures that the right document is selected, and the process can be automated without error. but for all we know, it just sends an email to the author who might handle the request personally.
Razorpay has been such a terrible experience for me as a consumer, that I'd actively avoid using it as my payment processor.
I know at least 3 scam operations having their payments processed through razorpay, and these are proper scams selling non existent products. So far all my complaint emails to razorpay have gone unanswered.
Have the entire world change their implementation rather than the one company which is doing it wrong?
This is not how RFCs work. There's a reason RFCs came about, and it was to prevent this exact type of situation. Just because a company has a large market share, doesn't mean RFCs should be changed to suit it.
Because if they didn't pretend that it was the same to fly a 737 and a 737 max, then they would be required to have pilots get a separate type certification for the max, which is costly for airlines and makes the airlines very reluctant to order the max.
Wow, $1 for 100 emails is very very very very expensive. So expensive that I'd opt to build this in house rather and take on the costs associated with it and still come out saving money.
> I'd opt to build this in house rather and take on the costs associated with it and still come out saving money
This seems to be the default position of almost everyone in IT, everywhere I go. People make this claim without doing any calculations.
I can imagine building this in house would be at least a few weeks of developer work and some more devops. That's tens of thousands of dollars. You'd have to send a million emails to break even. How many of this kind of transactional email do you send per year?
Anyone that’s at a scale where this is connected to business certical workflows is likely equipped to build this in house at a fraction of the cost. In terms of level of effort, this product itself is a rounding error.
Go talk to your vendor management team about getting a $2/mo contract signed. What does support look like because if this goes down at 2 AM, business is impacted.
Legal needs to review because it is sending employee PII (emails, phone numbers, etc) to a third party, who now knows the individuals in critical "approval roles".
Next hit up security and have them do an audit since this is going to be part of a security control. For bonus points, the internal pentest team finds a bypass that ApproveAPI needs to fix.
Your $150k a year developer is now spending 3-5 hours a week for 3 weeks shepherding a vendor onboarding for something they could have built and tested in a few hours.
Yes but your internal developer still needs to go through legal and security for the same reasons, as well as the internal pen test. The only thing you get to skip is vendor management.
And in most cases, vendor management isn't going to get involved for something that will be expensed on a credit card for $2/mo
No one does this “approve 10 things a week with a 5 person approval” flow that isn’t already done in some organized platform or system. Where on earth is this use case happening that this is both a valid use case and a savvy enough customer to buy this solution? This is not a thing.
> This seems to be the default position of almost everyone in IT, everywhere I go. People make this claim without doing any calculations.
I constantly see people not even considering what it means to be giving (potentially critical) business processes away to another company, not having any real knowledge in house, and not realizing that sometimes partners suck and won't help you fix problems in their software.
Neither is a sure bet all of the time, but just dismissing pulling things in house neglects a lot of other downsides to outsourcing.
I think that's a bit strong without talking about use cases.
Approvals here cost ~1¢. Picking a figure of $100k as a developer salary (as it was the first result in a quick search) that puts a lowish bound as about $400/day. So you could take your estimate of build & maintenance times per year, multiply by about 40-50,000 and that's how many approvals you're looking at.
So if you're google doing this every login, sure, that would be prohibitively expensive. If it's my accountants site doing it before they charge me a different amount for filing (there's one of these every year) or being the approve/reject part of an HR holiday system, or anything less common you'd have to be pretty big before it'd be worth spending a day or so building it yourself.
Personally I could see myself using it in some automated workflows I'm building now. Script runs, but before it does something irreversible (e.g. ordering an item) it checks with me that things look OK. It'll cost me a tiny fraction of the total spending, and it's ready right now (and works!).
Felt the same, though it really depends very much on your use case. If you end up in the thousands of daily approvals, then yes, that would be immensly expensive for the service it provides
Hey -- one of the creators here, thanks for your comment. We definitely don't want to price out companies from using our service so we are listening carefully.
I also want to mention that we do support volume pricing, so if you want to send lots of approvals per month we can work together on a price that makes sense for your use case -- just reach out to us at support@approveapi.com.
You are clearly baking in your Twilio/Mailgun costs in to the per-approval price. Why not just let me provide an API key and charge $5/mo for the service itself?
On average, a boring approval wastes maybe 1 minute between the requester waiting and the approver opening whatever system they use for approval. Over 100 approvals, this is 100 minutes wasted.
At $100 per hour for a professional, you could save around $159 by using this service.
Seems like the pricing works out to me. You just have to figure out how much time is wasted in traditional approval and how much time this approval method saves the customers.
Thank you for this. I think the prominence of YC will bring much attention to this space.
The approach that the kidney project is taking is very promising. It expands on the current dialysis method. Improved filtration but self contained in the body. No need to lug around a heavy machine. No regular clinic visits. 24x7 cleaning of blood. Reduced chance of infection. No rejection issues unlike transplants. The cost savings vs current dialysis is mind-blowing. Back in the 80s, our current dialysis method was in their infancy until new materials (plastics) made them feasible.
Actually a lot of email addresses cannot be validated this way since most ESPs including gmail have adopted an 'accept-all' approach to incoming email. So getting the email accepted by the server is no indication that the address exists, or that the email will actually be delivered to that address even if it exists.
