Critique my SMS Twilio web app/idea

9 replies
Ok so I finally made a web app to connect with Twilio API to send sms/mms texts to subscribers in various groups. Currently working on a web form to let people add themselves to the proper group automatically.

App has the basics, create groups, upload/download cvs of users, scheduled texts, message templates, see history of what was sent.

I was originally going to use it just for my own purpose. But now am thinking that maybe I should try to sell it so small businesses can start their own sms campaigns. Really haven't seen many apps like this that will keep it simple and keep it cheap.

So here is my concept, let me know what you think of it and if pricing is good?

I install the app on their website (password protected area). Train them how to use it (super easy). Help them sign up for Twilio (super cheap texting, .0075 per text). I charge $19.99/month. So to them even if they have just a few hundred subscribers its a very cheap, customized solution. Maybe a $99 setup fee?

Do you think this will work? Any tips or ideas for me?
#app or idea #critique #sms #twilio #web
  • Profile picture of the author GooderIsBetter
    I think you should try and sell it to see if there is demand for it. Marketing this is going to be the hard part I would think.

    What is the problem that you are solving? Why do I need this?

    I like the idea if you can pull it off. I've had similar twilio ideas but never pulled the trigger.
    {{ DiscussionBoard.errors[9932868].message }}
  • Profile picture of the author vndnbrgj
    I don't think you should sell by individual texts.
    They should be bundled. 1,000 texts for price A
    2,500 for price B. 5,000 texts for C.
    If a customer goes over, they can purchase more at 100 or 250 increments. Or you could charge more per individual texts.
    Signature
    Life Begins At The End Of Your Comfort Zone
    - Neale Donald Wilson -
    {{ DiscussionBoard.errors[9933184].message }}
  • Profile picture of the author jamesfreddyc
    If you are just using the API to submit from your site to Twillo...

    Have you tested your service under loads?
    What happens when you have 10, 25, 50, 100 concurrent users submitting 1000 outbound messages?
    Are you throttling the input?
    Do you know how many outbound messages can be submitted to Twillo per second?

    You may want to consider how to scale once you get going because it's incredibly difficult to rebuild architecture if it was not designed properly from the start.

    Edit: from what I can tell Twillo limits their sms sends via the API to 1/sec per phone number. If so, you BETTER have multiple numbers that allow you to round-robin/cycle thru! Your users will be p'od if it takes 1sec per message! Also, have you implemented asynchronous processing into the application? If not, your users will sit there forever as they attempt to send their messages, or most likely it will time-out and fail.

    If you use shortcodes then you will get better performance at 30msg per second. Still, you will need to build a queue system to process requests no matter if it's long or short codes.
    {{ DiscussionBoard.errors[9933377].message }}
    • Profile picture of the author pwk2000
      Originally Posted by jamesfreddyc View Post

      If you are just using the API to submit from your site to Twillo...

      Have you tested your service under loads?
      What happens when you have 10, 25, 50, 100 concurrent users submitting 1000 outbound messages?
      Are you throttling the input?
      Do you know how many outbound messages can be submitted to Twillo per second?

      You may want to consider how to scale once you get going because it's incredibly difficult to rebuild architecture if it was not designed properly from the start.

      Edit: from what I can tell Twillo limits their sms sends via the API to 1/sec per phone number. If so, you BETTER have multiple numbers that allow you to round-robin/cycle thru! Your users will be p'od if it takes 1sec per message! Also, have you implemented asynchronous processing into the application? If not, your users will sit there forever as they attempt to send their messages, or most likely it will time-out and fail.

      If you use shortcodes then you will get better performance at 30msg per second. Still, you will need to build a queue system to process requests no matter if it's long or short codes.

      My plan was for each biz to have their own Twilio number and just use their personalized version of my app to send their own texts. So each biz has their own app to use. If it goes down would not affect other versions of the app (unless there is an issue with Twilio API). Local number is $1/month.

      I guess I was thinking this would be cheaper for the biz then other services. For example Eztexting charges $50/m for only 1,000 messages and 1 keyword.

      My service would cost the biz almost half of that and they would get unlimited keywords.

      EZtexting elite plan is $149/month for 3,300 messages and 3 keywords. Their cost with me would be $19.99 to me and $25.75 to Twilio. Just 1/3 of the price.
      {{ DiscussionBoard.errors[9935716].message }}
      • Profile picture of the author jamesfreddyc
        Originally Posted by pwk2000 View Post

        My plan was for each biz to have their own Twilio number and just use their personalized version of my app to send their own texts. So each biz has their own app to use. If it goes down would not affect other versions of the app (unless there is an issue with Twilio API). Local number is $1/month.

        I guess I was thinking this would be cheaper for the biz then other services. For example Eztexting charges $50/m for only 1,000 messages and 1 keyword.

        My service would cost the biz almost half of that and they would get unlimited keywords.

        EZtexting elite plan is $149/month for 3,300 messages and 3 keywords. Their cost with me would be $19.99 to me and $25.75 to Twilio. Just 1/3 of the price.
        I was under the impression that you have built an application using the Twillio API that your customers will use.

        Even with each customer having your app using their own Twillio number, it still will only send 1 msg per second. Even with just a modest SMS campaign of like 5000 msg sends:

        5000 seconds = +80 minutes to process!

        That is some serious latency. Plus if your application is not implementing asynchronous processing then the user will be sitting there for 80 minutes as the applications attempts to process all of those. Won't it just time out?

        This is what I was saying before ---- you better have some kind of message queue system setup that will allow users to submit batches of messages and be able to rapidly process each one faster than 1 sec each. That means MORE rented numbers that you can round-robin the send requests. I wouldn't rely on twillio's queueing system.

        What is your load testing saying? How long does it take to process 100, 200, 500, 1000 messages? Do that and give yourself a good idea of what will happen. Maybe I am misreading your design and Twillio's API --- I am coming from the perspective of a whole-source provider though that uses a bulk SMS gateway that is cheaper than twillio.


        Edit: It's right in the API docs Twilio Docs - API REST Sending Messages

        Rate limiting

        You can queue as many messages as you like, however Twilio will only send out messages at a rate of one message per phone number per second. It is not possible to adjust this rate, and it does not vary based on the country in which your number is located.

        If you anticipate the need to send out a large number of messages quickly (a time-limited promotion, for example) or at a rate greater than one message per second, you can purchase additional numbers, increasing your outbound capacity.
        {{ DiscussionBoard.errors[9935781].message }}
  • Profile picture of the author jamesfreddyc
    Originally Posted by pwk2000 View Post

    Train them how to use it (super easy).
    LOL! I can tell you haven't worked with a business owner yet!

    Help them sign up for Twilio (super cheap texting, .0075 per text). I charge $19.99/month. So to them even if they have just a few hundred subscribers its a very cheap, customized solution. Maybe a $99 setup fee?
    You are missing out on a huge revenue source: the per/msg charge. Seems like you are going for being a host of some sort and not really participating in the app portion. What happens with support when the app breaks? How will you finance the upkeep of the app?

    Do you think this will work? Any tips or ideas for me?
    Sure you'll get some customers I bet but you don't seem to be considering the application as a piece of software (which it is) and how you intend to support it or generate revenue from it.
    {{ DiscussionBoard.errors[9933391].message }}
  • Profile picture of the author jamesfreddyc
    Originally Posted by pwk2000 View Post


    Do you think this will work? Any tips or ideas for me?
    Another consideration: CAN-SPAM compliance.

    How do you intend to handle the opt-in and opt-out process?

    For opt-out's, you will need to be able to process inbound REPLY messages from the recipients and update your client's customer list so that they no longer receive additional messages.

    For opt-in's, will you provide this capability for your clients in the application?
    {{ DiscussionBoard.errors[9935800].message }}
  • Profile picture of the author TrumpiaTim
    Just curious, for clients that prefer to send via short code instead of long codes, how are you planning to address those inquiries?
    Signature

    www.Trumpia.com

    Trumpia: The Most Completed SMS Text Messaging Software & API Solution.
    {{ DiscussionBoard.errors[9945943].message }}
  • Profile picture of the author Shoaib Khokhar
    So basically what you will do is take API from integrate it with merchandise website: Easy peasy lemon squezy.

    Where will be tech support or after sale service for that matter?
    {{ DiscussionBoard.errors[11113676].message }}

Trending Topics