TempNum - A Twilio Project
As many of you who follow me on Facebook or Twitter know, I recently launched TempNum, a (currently) free service that gives you a temporary phone number for three days to use for both inbound and outbound calls.
If you haven’t yet seen it, check it out (go ahead and sign up!) and let me know what you think.
Now that the service is launched, I thought I’d share a variety of thoughts about the project.
How Does It Work?
TempNum is incredibly simple to use. A user simply enters registers with a current telephone number that they use. They are then assigned a TempNum - a real US 10-digit phone number that is theirs to use for a period of three days.
A user answers an inbound call by simply picking up the phone. Calls to the user’s TempNum are forwarded to the user’s real phone without any action or awareness from the calling party.
A user places an outbound call by calling their own TempNum from their real phone. They are asked for the outbound number, and the call is connected with the TempNum as the caller ID.
It’s that easy.
Why Did I Make This?
A variety of different factors all came together at once, leading me to build this service.
Desire…I wanted to build something. I’m not a full-blown developer, but I do have some coding experience from various personal/professional projects and have always loved the satisfaction of building something. Bonus for functional and useful. I didn’t get to do too much of that while in business school (my work skewed more toward spreadsheets, regressions, and other quanty/analytical stuff), so I was eager to get my hands dirty on something.
Interest…In line with the above, I had some criteria about what I wanted to work on. I didn’t want yet another HTML/PHP/MySQL exercise. Yes, I wanted to utilize and re-familiarize myself with those tools, but I wanted to add on a layer of something entirely new. Luckily, I had become familiar with Twilio, a provider of cloud communications/telephony services. I’ve been a big fan of what their technology enables developers to do and was really interested in learning their API, understanding in detail how to use it, and incorporating it into my project.
Context…Finally, my recent move to California gave me some context for the project. My move provided me a more complex set of phone needs. On the one hand, I wanted a ‘local’ number without losing my current number or adding new lines of service. Google Voice was fine for that. On the other hand, I was using craigslist a lot for housing and furniture shopping, and wasn’t fully comfortable giving out either of my permanent numbers.
Thus - TempNum was born out of an interest in building something, a cool new API that I wanted to use, and a relevant problem around phone numbers that I wanted to try to address.
Under the Hood - Technical
HTML and PHP drive the basic functionality of the website. A MySQL database is used behind the scenes to manage user info, registration periods, and assignment of TempNums to users.
The Twilio REST API is the powerhouse for pretty much everything the service “does”, from provisioning phone numbers to initiating inbound and outbound calls.
What I loved most about the API was that I could use PHP - a language I am familiar with - to interact with it. That meant I was spending more time learning what I could do with the actual API, and less time learning the details of TwiML (their markup language which I admit is really concise and simple to use) or the basics of an entirely different web programming language.
Under the Hood - Functional
The basic call forwarding functionality of the service is described above. The original idea was to set up a simple service that was essentially a front end for Twilio for use by the average user. That is - the service would do nothing more than provision a number, set up forwarding and allow inbound and outbound calls, and a few days later shut everything off. These are pretty simple things to do for anyone with a Twilio account and OpenVBX, but I wanted to make something requiring as little effort from the average non-technical user as possible.
As I began to build the basic functionality, I started realizing the very real costs of running this service, the largest of which seemed to be the cost of acquiring phone numbers. At $1/month each (plus usage fees), it didn’t make much sense to buy a number, use it for only three days, and release it. Instead, I could use a number multiple times and lower my average cost of servicing a user. Thus, I decided to build a dynamic inventory of numbers for TempNum. Numbers could have one of four states:
Available - Acquired from Twilio. This number is sourced and ready to be assigned to a user. If numbers aren’t available at the time of a user registration, a new one is grabbed from Twilio.
Assigned - This number has been assigned as a TempNum to a user and is actively in use.
Unavailable - This number was once assigned but has passed the expiration. It is currently in a waiting period before it will be reassigned. The waiting period is designed to eliminate potential wrong numbers/user confusion in between assignments. After the waiting period, the number becomes available again.
Inactive - This number is no longer owned from Twilio and can no longer be used. I release all unassigned numbers (Available or Unavailable states above) at the end of the month. This lets me get rid of ‘unused’ numbers before Twilio bills me for the next month.
Basically, numbers go through the following cycle:
Available —> Assigned —> Unavailable —> Available —> Assigned… [repeat]… —> Inactive
Ultimately, I am able to recycle numbers to maximize their usage, and expand and contract my inventory to minimize unnecessary costs of number ownership.
What’s Next?
My original intent for this project was to exercise my basic dev skills and learn a new company’s API. But simply going through the process of building this got my head spinning about what to tackle next - both from a business and a technical perspective.
I’m not quite sure whether this is something I’ll devote all my time to or launch as a full-scale business, but here are some things I’d like to do next:
- Get qualitative feedback from users about likes, dislikes, feature wish-lists, etc.
- Understand usage, both by talking to the users and by analyzing the data from Twilio and my own database. Perhaps automate some analytics/reporting
- Implement some sort of SMS functionality. TempNum is currently voice-only
- Explore different pricing models. I’m currently supporting three day terms of service out of my own pocket. But there are a definitely a variety of pricing models I could explore should this take off, i.e. premium pricing for longer registration lengths, tiered usage, etc.
What do you think?
Whether you’re a developer, user, or casual observer, I’d love it if you checked out TempNum and told me what you think. Drop me a note: support at tempnum dot com
Thanks!
