Ask HN: SMS-enabling an app for a startup | Hacker News Reader

Ask HN: SMS-enabling an app for a startup

I'd like to write a little app that performs a little service. As part of that service, it receives and sends SMS messages.

If successful, it might not be unusual for an average customer to send and receive 50 SMS messages a week from my app.

Is there some way to create this without getting into spending a lot of money? I checked into Twilio, but just by creating the app and sharing on HN, I could be out several thousand dollars from people just playing around. Isn't there any way to do this more cheaply?

View on HN

If successful, it might not be unusual for an average customer to send and receive 50 SMS messages a week from my app.

Will this create $20 a month of value for them? If yes, charge $20 a month, pay e.g. Twilio $2 a month for your most active users and mouse droppings a month for the majority of your users. Problem solved. If your app does not create $20 of value when getting someone's attention 200 times, why bother making it?

There's a app out there which, essentially, provided a particular type of SMS services to a user population who thought SMSes were expensive. They grew like absolute wildfire, because the company underwrote their SMSing. They had no monetization in sight, because their core customers were too poor to pay for SMSes, and (luckily) got acquired before their telecom bill exceeded several million dollars in funding. If that is a trajectory which sounds appealing to you, well, that's an option, too.

The model I'm thinking of is freemium -- allow free usage over SMS for most consumers, then charge for those who sign up for business-level features.

What's got me thinking is that, unlike a classic website/app model, using SMS means I could be burning quite a bit of cash. Heck, it meas some random competitor could just start making me spend money for nothing (From what I understand, guys like Twilio will charge you for incoming texts even if you don't want them) It's like opening up your wallet and asking people to take money out of it. A very different model from the kind of control over costs I'm used to having.

But perhaps I am borrowing trouble.

Single accounts per device id/email/etc. with a usage throttling on free accounts would greatly limit competitors from blasting your system with spam that you'd have to pay for.

As far as not losing money in general, twillio is a great service but it's also one of the more expensive. There are competitors now so shop around a little bit. Overall though you'll most likely have to have a good advertisement system, some type of affiliate sales, or initial paid users to keep it running for awhile without investment backing.

I spent a year with a friend trying to figure this problem out. We created a real-time Craigslist, allowing communications over SMS, XMPP, email and voice, and hooking up buyer and sellers to talk to each other based on best match of keyword, price, location. We only allowed a handful of friends to use the service for our own testing.

The only real options we came up with were:

- charge sellers enough to compensate for all of the SMS traffic

- only allow SMS on paid accounts (still doesn't solve the problem of being charged for all incoming SMS, whether you respond to the SMS or not)

- find investors

The route we took was to convert it to a product targeted at businesses.

We use TextMagic for our app in the UK. Our app sends an SMS notification to a customer when they have time critical thing to look at. We really like TextMagic because there's no cost for us receiving & processing an inbound SMS (i.e. a reply from the customer).

There are a bunch of ways to help limit outbound SMS:

• Limit your hours. We only send SMS from 09:30 to 20:30. • Anything that happens out of those hours, put into a "digest" format. "You had four macguffins overnight." • If there are "busy periods", queue messages up so they get one per hour saying "You had 3 macguffins in the last hour".

Hope this helps.

Agree with the safe hours piece. People really hate it when you text them at 2am ;)

Implied but not stated: better be sure you limit your service by geographic area --or-- that you have really reliable location data for the users. My 2 AM is someone else's prime texting time. :-)

easy enough to sniff their local time with javascript though

Three words: Invite only beta.

Ask people who are interested to put in their emails and when you have the available funds for X freemium users (maybe by some paid-for service) release X invites.

Are you sure you want to do this over sms? Almost everyone has a smart phone these days and smart phones usually support push notification, which makes any messaging as integrated as receiving sms messages.

SMS is an archaic system with costs kept artificially high by telecom operators, there's no way around that except for doing your stuff over the internet.

> Almost everyone has a smart phone these days

In your social circles perhaps? Most of the world does emphatically not have a smart phone, and dumb phones still sell very well (more affordable and better battery life, for one). Go to any transport hub in Mexico for example and you won't find vendors hanging hundreds of styles of Androids and iPhones from their umbrella-shaded stands.

Another point is that internet connection is unavailable just too often. I don't know of all world, but even in Moscow the connection in some districts is very unreliable. I'm not talking of 3G, but of any wireless internet.

Wouldn't want a bank notify me of transactions with such unreliable means.

I had a client of mine in UK who wanted to send out a crazy 100,000 SMS everyday for marketing to opt-in subscribers. Of course, due to low margins he could not afford a web based SMS service. The successful solution I provided him was using Kannel to set up a SMS server which used to operate around 120 3G modems to send out those many messages in around an hour. Now of course, this method has flaws of its own in the sense that it requires your SMS server to be connected to the internet 24x7 something which can be hard but you could use some local datacenters to do that for you. In India, typically web based SMS services cost around 0.1 cent for a single message so most developers use that but if you are targeting a global audience then the choice can be really difficult. Anyways if you do need some consulting or development on SMS applications feel free to reach out to me on info [at] akshayagarwal [dot] in

We love Tropo for our SMS notifications at NodePing. They're pretty inexpensive US and international and are complete free for development. Another option would be to use the common email-to-SMS gateways for sending SMS... I'm not sure if you can receive replies that way or not.

Depending on what kind of scale you are looking at you can get SMPP connections which should offer lower cost and beter throughput.

Depending on what your product is individual operators maybe willing to help.

Note - I work in TheLab part of Telefonica.

Hey, what would be a good resource to start of for SMPP for a programmer who does not have much telecom background? I'm mainly trying to understand how a vendor flexible solution can be built for M2M

Someone who has worked with SMPP here.

SMPP is pain in the ass (I mean - it's not something you want to tackle with if you do not have about 2-3 spare months of your time..) and normally you would pay for SMS far less when sending them through intermediaries over some basic HTTP(S) interface. Using SMPP or any other "enterprise-grade" protocol possibly means connecting to telcos directly - and believe me, it's an expensive path to go..

Anyway, if you still want to go with SMPP, feel free to contact me, if you require paid assistance (I'm a freelancer). spiritus [dot] emortus [at] gmail [dot] com

We use https://github.com/raykrueger/ruby-smpp in our Ruby Apps to connect to the SMSC gateways.

It is not a 2-3 month integration but does require you to have a clue about telco's and depends on how you integrate.

If its less than a few thousand messages a day I would go for HTTP too.

An option for free SMS is to use the free gateways that a large majority of carriers have set up. I have yet to find any legality against using them, and would be interested if anyone had any information on it. It takes a touch of time to set it up, but it is free. If you choose that route then you can send an SMS message as a standard e-mail, and it's relatively easy to then monitor an inbox for responses.

My SMS Carrier Data http://www.visionsofafar.com/SMSCarriers.csv http://www.visionsofafar.com/SMSCarrierGroups.csv

I've done a ton of SMS research, and the price Twilio charges for SMS is very competitive.

One time I had this crazy idea that I never followed through on. Take several pay as you go cell phones with unlimited texting, connect them (bluetooth or USB) to your server, and send out messages through the phones. It's likely to be against the Cell company's TOS, but it seems like it would work.

Also, investigate the SMS alternatives. Since almost everyone has a smart phone, push notifications (or even boring old email) is almost as good.

Have a look at txtweb.com - a free platform to build SMS apps. You can get started here: http://developer.txtweb.com/

Users can access your app by texting a keyword to txtweb's US number(s) mentioned here: http://www.txtweb.com/index.php?option=com_myblog&blogid...

With Twitter what we did when we launched originally was simply get a PCMCIA GSM card and used some windows software to post it to the website via a protected REST api. Now i guess you could use a usb gsm modem. Worked great for prototypes. Now i guess there are services, but really the usb gsm modem method works well even today.

You can't charge for SMS that way and technically you're supposed to use a short code for automated sms sending. Short codes are very expensive, so don't do that til much later.

> technically you're supposed to use a short code for automated sms sending

FYI, I believe this requirement is USA only.

I have never actually used it personally, and it may be too difficult to integrate into a startup, but to get things rolling you might try looking at Frontline SMS: http://www.frontlinesms.com/

Set it up yourself, get a couple of phones with unlimited texting packages and incoming texts will be paid for by the user.

As I said don't have any experience actually working with it though and don't know how easy it is to integrate into a custom app.

SMS on Twilio is a penny. So drop $20 into your account and you should have lots of room. You can also limit/throttle messages to start.

I got a ton of traffic from being on the front page with this Twilio app last year:

https://news.ycombinator.com/item?id=3364942

And, to be honest, it didn't cost me much.

Also, I know the folks at Twilio pay attention to HN, so if you get some exposure, you may hear from them (I did).

Unfortunately you won't be able to spread the word on HN or other social media sources until you have some revenue. If you're offering me free SMS - of course I'm going to use it, and I might not be likely to pay for your business features.

Solution: create this product and market it right to businesses. Once you have a nice clientele, feel free to show it off to the world.

http://smsified.com/ has been in beta for ages, (looks like the free beta is now closed). They're not too bad, in terms of pricing (1¢ per sms)

twilio is 1c/sms as well - the OP's point was that letting people test/play with it gets expensive, even at 1c/sms.

are your customers US only? if not read on..

There are several aggregators you can use that can do the job for you via smpp (some even have HTTP APIs). The company I work for is running a web based sms service and we send our sms through InfoBip, TynTec and AMD Telecom (this one is a bit dodgy I don't recommend it). The prices vary from aggregator to aggregator so its best to try use more than one to optimize your cost per message.

Hook up a phone via USB and send it AT commands.

Nexmo tends to be cheaper than Twilio

If you expect your average customer to send about 50 SMS a week, why not charge them? Offer them a monthly plan to cover the cost of the texts plus some profit.

Reply on news.ycombinator.com