I think you can charge a lot more than 5c for this service. I think developers tend to think about margins as it relates to the service that the app is built on (this case twilio). Even though they charge 1c per text, you need to base your pricing on what a verified phone number is worth to someone using the service. If a verified number is worth 10$, you can probably charge more like 20-30% of that (maybe more).
But the target customers are developers. If this is simply a productized Twilio API, then it's not a huge time savings for a developer. If you need to verify users, it means your app is structured such that there's already a back end, and you already need to store a user record. Generating a random number, putting it in the user record, and calling a Twilio API isn't really a huge drag.
Considering DNS propagation, is "real quick" even possible? You might do better to take a bit of a cost hit and work within AWS. Assuming you're set up with an Elastic IP, maybe spin up another instance and an Elastic Load Balancer?
Edit: Either way, whatever you did it seems to be back up (at least for me).
I built something thing like this using Twillio for my Caller ID test tool. Visiting the site creates a unique pin number and you have to call in and enter it.
This looks like a cool service, and I am starting on a new project that might benefit from something like this. But the page failed to load 3 times, and the 4th time it took about 10 minutes to load. Maybe you are just getting overloaded from HN visitors, but still, that's a problem.
Do you also offer this as a service that can be implemented natively from another application? In other words, I'd rather not go to your homepage to do this, I'd prefer the customer add his/her information on my website, and have the processes automated with the results sent to me.
This is one of the biggest headaches I have as a developer of two mobile apps that require number verification. But the headache isn't because the twilio/nexmo/clickatell/etc APIs are too complex, or because I don't want to deal with adding a single verification code column to a user record in the DB schema, but because the delivery success rates for the SMS gateways I've been using are quite bad.
Most of my time is spent trying to figure out which mobile networks which SMS gateways will deliver best to, and then directing the correct verification traffic through those gateways accordingly. Which is a nightmare, in part because the successful delivery rates for different areas and networks constantly changes.
If this is the problem that Prove is solving, I think emphasizing that (or at least mentioning it somewhere) on the website is important. I would be an eager customer.
Disclaimer: I do a bit of part time dev evang for Nexmo.
Nexmo should be pretty good across the board as it pertains to what delivers best (direct to carrier model: http://blog.nexmo.com/post/4690069179/directsms). In that way, Nexmo is trying to solve the issue you're having.
Have you had any issues with deliverability and Nexmo (where another provider delivered better)? Nexmo actually provides some tools to automatically optimize traffic based on client conversion ratios.
I haven't had very good luck with Nexmo and deliverability. I wanted to migrate all my traffic there, but had to stop after a few %-tests resulted in increased failure rate. I do still use them for some areas/networks they seem to do better with. I also appreciate their good customer service.
I'm sure the team would appreciate the feedback as to where the deliverability was less than another provider. Also, might want to ask about the recently added tools to use your conversion stats to help route traffic.
Sorry to hear that. I am part of Nexmo helpdesk and we are here to help you address any issue you are seeing. Can you share with us more info on the issues? message IDs? phone numbers? account? best is that you drop us a ticket at nexmo.zendesk.com and we would love to assist!
Duo is for two factor authentication, where my impression is that this is for signup verification.
Consider mobile apps like WhatsApp, which use your existing mobile number as your identifier. This makes a lot of sense for a bunch of reasons, but it requires the app to somehow verify that the number you enter is actually your number. This is commonly done by having the service send a verification code in an SMS, which you then enter back into the app.
10 years later, and this is still a challenge. My biggest regret is not taking this technology and putting an API behind it and offering it up. Oh well.
This is definitely cool, but it's just one thing that any "social framework" would do. Verifying emails or verifying mobile phones is a basic step in any user signup.
This is a bit off topic, but I don't own a cellphone and the verify via SMS trend is starting to worry me. It would be better if it had an option where it called and used text to speech for the autogenerated pin, but I probably would not give my phone number to the vast majority of sites anyway.
You might want to look into getting a prepaid phone of some kind, even if it's not a smart phone. Having a portable emergency communication device seems like a good idea even if you're opposed (for whatever reason) to cellphone use in general, and a prepaid phone won't give you monthly bills or contracts to worry about.
If that's no good, then how about Google Voice? In addition to its other useful phone-related features, it allows sending and receiving of text messages.
My wife and I used to have tracfones. I just went and pulled mine out of the box here. It only says motorola on it, no model number or anything other than that. I really liked that phone, it was simple, great battery life, and got reception where others did not. What I did not like is that I paid more than $200 for them and about a year later tracphone said they would no longer work on the phone networks here. What a colossal waste of money that was. I'll keep spending my money on tools in case of emergencies. My wife does have an iphone with a contract now though.
Maybe I should do the google voice thing though, good suggestion, thanks.
I use Google Voice where possible, and especially for SMS. Regular SMS to/from my phone costs 20c per message (usual US carrier nonsense). I've found that most places that claim to send SMS fail to send to Google Voice, and provide no diagnostics that they failed. Given SMS supports receipt notification that is a strange.
I have the same headache with Google Voice not receiving most confirmation SMS and was delighted to see that the test SMS I just sent using this service came through. Well done!
57 comments
[ 2.9 ms ] story [ 122 ms ] threadI'm just regurgitating: http://www.kalzumeus.com/2011/12/19/productizing-twilio-appl...
(they do)
support@getprove.com
we simplified the entire process so you can integrate this within minutes and then down the road -- u could build your own solution if needed
Edit: Either way, whatever you did it seems to be back up (at least for me).
http://www.calleridtest.com
Twillio makes the development of things like this a breeze.
Always always always host the static bits in S3/Cloudfront or some other piece of machinery that can spit them out quick when you show your work off.
Do you also offer this as a service that can be implemented natively from another application? In other words, I'd rather not go to your homepage to do this, I'd prefer the customer add his/her information on my website, and have the processes automated with the results sent to me.
a) How huge an EC2 instance do you have?
b) What tech are you serving from? Express, ASP, JSP, etc...
the core problem was redistogo, not primarily ec2, though someone else takes up a lot of CPU on my shared instance
Most of my time is spent trying to figure out which mobile networks which SMS gateways will deliver best to, and then directing the correct verification traffic through those gateways accordingly. Which is a nightmare, in part because the successful delivery rates for different areas and networks constantly changes.
If this is the problem that Prove is solving, I think emphasizing that (or at least mentioning it somewhere) on the website is important. I would be an eager customer.
Nexmo should be pretty good across the board as it pertains to what delivers best (direct to carrier model: http://blog.nexmo.com/post/4690069179/directsms). In that way, Nexmo is trying to solve the issue you're having.
Have you had any issues with deliverability and Nexmo (where another provider delivered better)? Nexmo actually provides some tools to automatically optimize traffic based on client conversion ratios.
https://www.duosecurity.com/docs/duoweb
Once I can load the webpage will be interested to see if there are any differentiating features that make it easier to get started as a developer.
Consider mobile apps like WhatsApp, which use your existing mobile number as your identifier. This makes a lot of sense for a bunch of reasons, but it requires the app to somehow verify that the number you enter is actually your number. This is commonly done by having the service send a verification code in an SMS, which you then enter back into the app.
https://www.duosecurity.com/docs/duoverify
Why "oh well?" Not to be pedantic, but if it's your biggest regret, what's stopping you?
We thought about building something like this as a paid service, but we didn't think it could be very profitable.
https://getprove.com
i migrated assets to CDN, but still transferring some now, so fonts might now show up yet :)
If that's no good, then how about Google Voice? In addition to its other useful phone-related features, it allows sending and receiving of text messages.
Maybe I should do the google voice thing though, good suggestion, thanks.
When I try to sign up for an account I get an error "User already exists". This is the case for any email address I enter.
EDIT: SIGN UP WORKING