Marketing Secrets of Successful Startups

I am thrilled about the speaker line-up for the FutureM Marketing Secrets of Successful Startups event sponsored by Shopximity. It’s tomorrow, Thu 9/15/2011, 11:30 – 1:30pm at CSN (177 Huntington Ave in Boston, 24th floor). Hope to see you there!

[Tweet to tell your followers to come!]

You’ll hear from the following top marketers and entrepreneurs:

  • Adam Berrey, Free Agent. Adam has spent that last 17 years working in technology marketing covering the full spectrum from strategic marketing through marketing communications at companies such as Allaire, Macromedia and Brightcove.
  • Chris Hulls, the founder & CEO of Life360, is at the forefront of rethinking mobile marketing through the lens of value-added service integrations.
  • Chris Savage, Founder & CEO, Wistia, a startup he co-founded a year after graduating from Brown University with a degree in filmmaking. Chris was named a Best Young Entrepreneur by BusinessWeek in 2009. Chris helped produce and bring to theaters an Emmy award winning film, “Buddy.”
  • Christopher O’Donnell, director of product management at Hubspot, the inbound marketing company, where he arrived via the Performable acquisition. Christopher is a mentor to many and a well-known expert on performance-driven design. He likes making something amazing out of nothing.
  • Dave Balter, Founder & CEO, BzzAgent (Dunn Humby). A co-founder and current executive council member of The Word of Mouth Marketing Association, Dave is an international speaker on the topic of word-of-mouth marketing. Dave built and sold two promotional agencies prior to forming BzzAgent.
  • Sarah Hodges, Director of Community Marketing, Runkeeper. Sarah is a well-known digital marketer and blogger who practices a data-driven approach to marketing. She is an expert in viral marketing using emerging channels.
  • Sim Simeonov, founder & CTO of Shopximity and a board member of MITX, the organizer of FutureM. He invests in and advises startups through FastIgnite and is a TechStars mentor. Sim has been a founder, CXO, investor and board member at more than a dozen startups. He likes big successes and small failures.
  • Stephanie Shore, VP of Marketing, ZipCar. Stephanie is a marketer with deep intuition about both content and people. She is an expert at helping people express themselves within the context of a brand experience. Before ZipCar, Stephanie helped people make sense of the world around them through boston.com.

The hashtags for this event are #FutureM and #MSSS. Please, thank my co-host Christopher O’Donnell, our sponsor @shopximity, @wayfair (CSN) for hosting us in their great space and @FutureMBoston & @MITX for making it all possible.

Posted in Digital Media, startups | Tagged , , | Leave a comment

Mobile Marketing Frontiers

I am thrilled about the speaker line-up for the FutureM Mobile Marketing Frontiers event Shopximity has organized. It’s tomorrow, Wed 9/14/2011, 8am – noon at Microsoft’s NERD center (One Memorial Drive in Cambridge). For more info, check out the event description. Hope to see you there!

[Tweet to tell your followers to come!]

8:00      Opening remarks

Simeon Simeonov, Founder & CTO, Shopximity
@simeons | @shopximity

8:15      Keynote

Robert Tercek, General Creativity & This Week in Social Media
@superplex

9:00      Demos

Chris Grayson, Director of Digital, Humble
@chrisgrayson | @humbletv

Chris Hulls, Founder & CEO, Life360
@chrishulls | @life360

Seth Priebatsch, Founder & CEO, LevelUp
@sethpriebatsch | @thelevelup

Thi Wernau, VP Business Development, Skyrockit
@thilinh | @skyrockitsf

10:00    Fireside chat & audience Q&A

10:30    Networking break

11:00    Executive panel

Lars Albright, Founder & CEO, SessionM
@sessionm

Ron Elwell, Founder & CEO, Shopximity
@ronelwell | @shopximity

Scott Meyer, Founder & CEO, Evidon
@scottmeyer | @evidon

The wireless guest code for the Microsoft space is fm912.

The hashtags for this event are #FutureM and #MMF. To follow all the speakers & companies at the event and more, check out my Mobile Frontiers Twitter list.

Please, thank our sponsors @shopximity & @gcvp, Microsoft for hosting us in their great space and @FutureMBoston & @MITX for making it all possible.

Join us tomorrow (Thursday, 9/15/2011) at Marketing Secrets of Successful Startups: 11:30-1:30pm at CSN (177 Huntington Ave in Boston). Hear from marketing gurus who have grown ZipCar, Hubspot, BzzAgent, Wistia, RunKeeper & more.

Posted in Digital Media, Mobile, Shopximity | Tagged , , , , , | Leave a comment

One line Tropo debugging gem

I’ve worked with Tropo, a cloud telephony platform, for a few months now, primarily using the Ruby scripting API. Tropo’s script execution model is a bit strange–the script file is pre-pended with a bootstrap block of code and the combined stream is executed inside a JVM (so it’s JRuby, really). Stack traces in logs report line numbers from that composite file, which don’t map to line numbers in the the source script–they are offset by the bootstrap code block’s length. My most useful Tropo scripting debugging aid is the first line of my Tropo scripts:

$currentCall.log "---- Tropo first line offset is #{__LINE__}"

This is how I know to subtract 215 from the line numbers to map to my code.

Posted in Code | Tagged , | 1 Comment

How to set up reference checks

Swoop (what used to be Shopximity) is in full-on recruiting mode. We are looking for both experienced and up-and-coming full stack developers who love startup life, open-source tools, cloud deployment and are deeply plugged into the tech ecosystem. I’m having a blast meeting with great engineers.

The part that is proving less fun is setting up references–it just takes too long to schedule them and it slows the entire recruiting process down. In fact, a back-channel reference currently takes me about 3-4x less time to get to than one a candidate provides.

The typical process for setting up a reference check goes like this:

  1. Hiring manager asks for references
  2. Candidate sends emails to several people asking for a phone call
  3. Scheduling back and forth
  4. Candidate talks to reference about opportunity
  5. Candidate shoots an email intro to reference and hiring manager
  6. Scheduling back and forth
  7. Hiring manager talks to the reference

The process takes too long because scheduling happens twice, serially. A better, faster way to make things happen is for the candidate to send an introductory email along the lines of the following:

Joe, Sim (http://linkedin.com/in/simeons) is recruiting me to [the ground floor team at his new startup] Swoop. I’m interested in the company because they are solving some very hard problems at the intersection of search, content & advertising–areas that I have a lot of interest in. I’d appreciate it if you took some time to give him a sense of what it’s like to work with me and what I bring to a venture. You can reach Sim at xxx-xxx-xxxx.

Sim, Joe (http://linkedin.com/in/wiredbrainjoe) was CTO at WiredBrain back when we were working on the mobile SDK for brain implant location tracking. He recruited me to WiredBrain in 2005 and was my boss until 2008 when I left to join Google. You can reach Joe at xxx-xxx-xxxx.

Best regards,
Candidate

Here are the top three reasons why this works so much better:

  1. The candidate comes off as more confident because they are ready to make a direct connection with a reference. The process moves faster. A decision is reached sooner.
  2. Candidates save time because they are out of the scheduling loop. If a candidate wants to talk to the reference first, he can send a separate email to the reference and not include phone numbers. Otherwise, adding phone numbers helps because sometimes one can squeeze a lot more calls in a dedicated block of time as opposed to having to schedule every single call.
  3. The email provides context that’s helpful to everyone and makes reference checking more efficient. There is information about the two people who are about to talk. There is some information about the company and the candidate’s interest which can be helpful to the reference. There is also information about the context of the relationship between the candidate and the reference and the type of work that was done which helps a hiring manager set up an efficient reference check.

Last but not least, don’t set up just a couple of references. Set up lots. The hiring manager doesn’t want to and probably won’t talk to all of them but they’ll be able to get through a handful quicker and reach a decision sooner. It also shows a lot of confidence to set up many references. If you only set up a couple, there is always the question of whether these are the only people who know you and your work.

Posted in startups | Tagged , , , | 4 Comments

Shopximity wants to give you $10,000

I was prompted by a comment on a recent blog post about recruiting top engineers to formalize a simple suggestion I’ve made to startups over the years: if you have the money to use recruiters, offer a $10K referral bonus to anyone who helps you make a hire. That’s what we are doing at Shopximity.

The reason is simple. If a company is willing to pay $20+K to a recruiter for a great hire, why shouldn’t it be willing to split that bounty with someone else who gives them a great lead? It’s less about the actual dollars and more about the fairness of it. I’ve had people tell me they wouldn’t take the money. That’s cool. I can make a donation on their behalf or give it to a startup organization or a movement such as #RubyRiot.

The rules are simple:

  1. No spamming. Any referral must come with clear reasons why you think the person would be great at a ground-floor startup. Please, respect our time.
  2. Whoever refers a person first wins unless the quality of referral varies substantially, e.g., just mentioning someone you don’t know vs. mentioning a friend and offering an introduction. Within reason, the later but stronger referral would win.
  3. The usual recruiting fee restrictions apply.
  4. Yes, you can refer yourself.

Because of the strength of our founding team and our investors, we are going after some wonderfully tough problems. Here are the types of talent we are looking for:

  • From a culture standpoint, we want curious, high-energy, hands-on, know how to ship, agile everything engineers who take pride in their work and in making customers happy. People who see technology as a tool, not an end. These are the kind of people who know that a problem must be fixed twice: the first time to make it go away and the second time to make sure this type of problem never reaches production again. The best of them know how to have fun after work.
  • From a platform standpoint, we touch iOS, Android, Web and mobile Web (HTML5 + AJAX), Java + Python and/or Ruby. Hadoop and NoSQL work is guaranteed as is cloud deployment.
  • From a development process standpoint, we aim to be extremely agile with short iterations and very small integration batch sizes (continuous integration for sure with the goal of continuous deployment). This makes for the most satisfying, high-velocity environment to write code in.
  • From an experience standpoint, we are looking for both experienced senior/architect-level engineers who have “done it before” and rockstar junior engineers that can do it because they don’t know it couldn’t be done.
  • We are good mentors–check us out. It really matters to us that the people on our team have fun while developing in their careers so that they can do whatever they want (get promoted, start a company) next time around.

Here are some tips:

  • You don’t need to send a resume or get someone interested in working with Shopximity before referring them. Sometimes, the best thing to do is simply to identify someone truly great and let us take it from there. Shopximity is doing some pretty amazing things and so far everyone we’ve reached out to has been interested in being considered for our team.
  • Don’t worry about specific job titles–those are fairy flexible based on the candidates’ career goals and experience. Just point us to great people.
  • Mess with your competition: if your competitor has some great people on their team, tell us and we’ll recruit them away.

Let’s get going. Follow me @simeons and send me an email at sim at shopximity dot com if you have someone for us.

Posted in Shopximity | Tagged , , , , | Leave a comment

Getting developer interviewing right

Much buzz today on HN about developer hiring with Evan Carmi sharing his Google interview experience, which mostly consisted of language trivia and algorithmic tasks, and a devininterviews follow up arguing that this interviewing style leads to bad hires.

I don’t think there is one right developer interviewing technique. It is worth mastering a variety of interviewing techniques and then adjusting based on the job requirements, team composition, manager style and company culture.

Here is an initial (incomplete) list. I’ll update with new content from comments & conversations.

Programming language questions

Examples: what’s the order of C++ class data member initialization, how is the value of self determined in a Ruby block and what’s the difference between class and function decorators in Python.

Why: I want to know whether you know the tools of your trade.

Good for: quickly checking the box on language proficiency.

Useless for: determining whether you can code well in the language. I know developers who write kick-ass, elegant code using 50% of a modern language’s features. That’s awesome.

On-the-spot coding of algorithmic problems

Examples: write a binary search, write a Sudoku solution checker and write a substring search.

Why: I want to know which developer group you belong to: the folks who can solve algorithmic problems or the ones who could churn dozens of MVC screens but couldn’t build a fuzzy string matcher to save their lives, even with resources online.

Good for: vetting analytic thinking and coding precision under pressure as well as basic verbal communication & organization of thought. Bonus: easy way to see how you handle criticism.

Useless for: understanding how you’ll write practical code and handle criticism on a team. In the real world engineers solve problems not in front of a white board but at their desk, with Google, GitHub, their co-workers, hacker buddies, Twitter friends and the Stack Overflow community. If your development velocity is great, I most likely won’t care whether you do it by memorizing the algorithms textbook or submiting a dozen questions per week on Stack Overflow.

On-the-spot debugging

Examples: find the bugs in this listing or I have this project loaded in Eclipse and this bug ticket here — go at it.

Why: just as I want to understand your development workflow, I want to understand your debugging workflow.

Good for: getting a sense of how you wrap your head around other people’s code.

Useless for: being sure that’s how you’ll debug normally.

Take home programming tasks

Example: Here are two empty git repos. By 10am PT tomorrow build and deploy two applications on Heroku. The first exposes a REST API for logging session events with arbitrary JSON-based parameters and saves the events in an SQS queue. The second pulls events from SQS and saves them in a MongoDB database hosted on MongoHQ. You can use whatever gems you want.

Why: I want to get a sense of how you work in the real world. I want to look at the code you write but I care even more about what you consider “shippable”. Here are a few things I’d pay close attention to beyond the obvious code style/quality that you may not even know you’ll be evaluated on:

  • How did you deal with fuzzy requirements?
  • What was your git workflow: commit frequency/atomicity, batch size, branching strategies. How you use source control alone is a great indicator of how you’ll use source control on a team.
  • Did you choose Rails or Sinatra? Why?
  • Which AWS gems did you pick? Why? How did you evaluate the quality & fitness of a gem?
  • Did you use TDD? I don’t mean did you deliver tests in the end. I’m interested in whether the tests hit the repository no later than the features.
  • How extensive is your testing? Do you have integration tests? Acceptance tests? Did you set up dev & staging SQS queues?
  • Did you think about securing the REST API? How?
  • How do you manage sensitive info? Is your Amazon secret in the git repo or does it get set as an environment variable? What about the MongoHQ credentials? What about sanitizing the logs?
  • How paranoid are you about failure? Did you pop() from SQS assuming a MongoDB write will succeed or did you peek() and only delete from SQS when you know the message contents made it into Mongo?
  • Are you checking for duplicates in Mongo?
  • How did you set up Heroku? Do you have staging apps as well as production apps? Did you set up deploy notification hooks? How about monitoring for the apps?
  • Did you think about scaling? Did you write any code for it? Did you do any load testing? When does your current deployment break?
  • Did you write any docs? Do you know your audience?

Good for: a litmus test of your ability to build, ship, operate and communicate. Getting a “fingerprint” for how you work.

Useless for: deeply understanding how productive you can be on a team. There is no teamwork component here and it’s hard to separate the various elements that contribute to the final product: your prior knowledge and experience, help you get from a buddy or online resources, luck. Plus, to really evaluate your performance will take a lot of work.

Take-home debugging

Examples: (actual problem I used to give) here is a simple linked list implementation in C++. Find the bugs.

Why: just as I want to understand your development workflow, I want to understand your debugging workflow. Some of the bugs are subtle. I hope you talk to friends about the problem.

Good for: getting a sense of how you wrap your head around other people’s code and how you work with others to solve problems.

Useless for: determining how much of the outcome was “pure you” vs. “you + others”

High-level questioning

Examples: from devin interviews:

  • What’s the last project you worked on at your former employer?
  • Tell me about some of your favorite projects.
  • What projects are you working on in your spare time?
  • What online hacker communities do you participate in?
  • Tell me about some (programming/technical) issues that you feel passionately about.

Why: I want to get a sense of who you are as a developer and how you might work on a team.

Good for: knowing who to reject quickly and who might be a good cultural fit.

Useless for: deeply understanding who to say yes to. Bottom line: great interviewees can prep for and ace this because it’s too general.

Behavioral interviewing

Examples: tell me about a situation where you had to deal with a bug that only appeared under load in production + lots of specific follow-on questions

Why: two reasons: (1) other things being equal, past performance in similar situations is the best predictor of future success and (2)  behavioral interviewing gets down into the nitty-gritty and breaks through BS effectively.

Good for: drilling into specific areas of interest

Useless for: covering a lot of ground quickly and useless if the interviewer is not experienced in the technique and does not apply it in a disciplined manner.

I know I’ve missed many techniques and the “high-level questions” group should be broken into several. I’d welcome ideas on how to do it.

 

 

Posted in startups | Tagged , , | 13 Comments

The three rules of awesome mobile hackers

One of the reasons why I’ve been mostly absent from this blog is that, together with a couple of very interesting people, I started a new company and we’ve been busy closing our Series A and getting things off the ground. More on this in another post.

This post is about mobile developers or, most precisely, about talent development in the mobile ecosystem. In the past few weeks I’ve been recruiting, I’ve learned a few things about the current state of the iPhone/Android developer ecosystem that I’d like to get your thoughts on.

My new startup is at the intersection of mobile, local, retail and advertising. We are taking a contrarian approach in this bubbly space born out of deep customer relationships. Because of this customer connection, contrary to many others in the space, we have a pretty good idea of what needs building. It’s one of those “they asked us to build it and are waiting with their checkbooks open” types of situations. This doesn’t say much but it sets up the problem.

For us, user experience matters a lot but distribution matters even more. Distribution is why we are not going to build the 113th mobile-local-retail-advertising app. There are plenty of apps that touch the lives of shoppers. Rather than competing with them, we want to help them create a better user experience and make more money, in that order.

No, we are not an ad network. The above two goals are impossibly at odds with one another when an ad network is involved. Giving the bottom portion of an app’s precious screen real estate may make the app developer some money but certainly doesn’t improve user experience. We are doing something that’s never been done before on the client side that, if we solve some very challenging problems in an elegant manner, can both generate substantial revenues for app developers and lead to a stickier and more engaging user experience.

Technically speaking, we’ll integrate with apps both through existing services they use as well as our own SDK. We need to do some serious jiu-jitsu in order to make app developers’ lives easy. There is low-level device/framework work. There is also fancy GUI work. It’s stuff that’s never been done before on a smartphone. It’s the kind of thing that can improve the user experience of tens of millions of people. It’s the kind of thing I need awesome mobile hackers for, starting with the iPhone and Android platforms.

Here are the three core rules that, for me, define awesome mobile hackers:

  • They have done low-level mobile development. They don’t have to have worked on a mobile OS but they know and have rearranged the innards of mobile frameworks (or their desktop counterparts) such as Cocoa (Touch) on the iPhone and understand what it takes to do fast, efficient and reliable communication with servers. They have a thorough system-level understanding of how the device, the mobile OS, the high-level framework and the app coexist. This allows them, with hardly a thought, to power through the types of problems others post of Stack Overflow.
  • They deeply understand end-to-end mobile app development and lifecycle and have built a number of mobile applications. This allows them to relate to and empathize with the experience of other mobile app developers. That’s why awesome mobile hackers build tech other developers find sexy.
  • They are active in the ecosystem. They have lots of friends doing cool work. They know people on the iOS and Android teams at Apple and Google who will more often than not enjoy going out to lunch with them at a conference. They pay it forward. They contribute to open-source projects and mentor up-and-comers. This builds good karma, which invariably helps them out with life on the bleeding edge.

In the past few weeks I’ve come to believe that the iPhone and Android ecosystems are evolving in a way that fundamentally works against the development of awesome mobile hackers. This very much reminds me of the mid 90s when, as the chief architect of the first Web application server, I watched the explosion of the Web developer community. For a more recent reference, what I’m seeing in mobile from a talent standpoint is worse than the bubble in Ruby-on-Rails development. Here is why:

  • There is too much money to be made in consulting. Apps are churned out on a conveyor belt. The focus is on speed and reuse so why bother learning hard things such as low-level mobile development? Non-visible features pay less because clients don’t appreciate them as much. On top of this, mobile devices are locked down to an extent, which limits the practical value of low-level mobile work. Few try it and why even fewer become great at it.
  • On the flip side, many low-level mobile developers come from mobile OS backgrounds and, unfortunately, don’t like to build apps. Even when they do GUI work they tend to find it “below them.” This makes them blind to the perspective of app developers. Those are the guys that build wonderfully-architected frameworks that nobody wants to use.
  • In this crazy environment of excess demand, developers get very, very busy and spend much less time connecting with their peers, contributing to open-source projects, etc. Skill development becomes almost entirely job-driven as opposed to personal interest-driven. Foundation skill development doesn’t pay and is therefore deemphasized.
  • Conveyor-belt consultants, as opposed to long-term independent contractors or outsourcers, tend to lack appreciation of the ongoing lifecycle of an application post ship. Enough said.
  • The awesome mobile hackers employed by larger shops are used as fire-fighters across many projects. They gain breadth and exposure but lose depth. They also lose the motivation and satisfaction of owning the building and shipping of products. This numbs the soul of a developer and is a topic many top geeks at consulting companies have discussed with me over the years.

Don’t get me wrong. Consulting shops are not the problem. The market has set up a certain incentive structure and people operate within it to the best of their knowledge and abilities.

What I’m noticing, however, is that many don’t understand the opportunity cost of dumbing down the work they do from the standpoint of their market worth, personal happiness and long-term career. With the benefit of experience across many companies, bubbles and crashes, I’d argue that:

  • An awesome mobile hacker can make more money in an early-stage product company than in a consulting company but, more importantly, they’ll do this while having more fun and positioning their career better.
  • Great mobile developers don’t understand how much their career is suffering by them not investing in becoming awesome mobile hackers.

If you don’t trust me, talk to a top recruiter or some of the top geeks at the companies you wish you worked at.

The fine print: if you’re an awesome iPhone or Android mobile hacker who likes to solve hard problems that have never been solved before and doesn’t get nightmares from the thought that tens of millions of people will use your code daily then, hell, yeah, I want you on my team.

[Update] I’d like to highlight a point from the comments below in response to some private questions. I am dead serious about giving $10K to the first person who introduces me to someone I hire and I mean that not just for these positions but for any position I am also using recruiters for. It’s only fair to acknowledge the huge value that the right referral can bring to a company.

Posted in iPhone, Mobile, startups | Tagged , , , | 7 Comments

The rising power of the Google platform

If anyone ever doubted that Google is a platform company, check out the “Google SDK.” I’m putting this in quotes because what you find there is really an aggregation of a bunch of separate projects than a well-thought-out integrated SDK–that wouldn’t fit Google’s chaos by design operating principles.

That said, it’s hard to ignore the breadth and depth of what’s on offer. Or think about how, regardless of any theoretical openness, using many of these APIs in your applications would tie you and your data inseparably to Google.

I predict than within 2-3 years many projects that depend on third party APIs will start including a data and API portability review just as they have security reviews today. This will come as a result of more and more data living behind SaaS apps and online services, making cloud integration as common as enterprise integration is today.

 

Google API and SDK

Posted in Google, Uncategorized | Tagged , , , | 5 Comments

Eric Ries interview about lean startups

Lean startup meme inventor Eric Ries is in town. He will be at the Lean Startup Circle event on Thursday night. If you are lucky-enough to have gotten a ticket for this, either hold it tight or sell it on eBay.

For the rest, there is another chance. The good people at CSN Stores, an awesome and fast-growing e-commerce company in Boston, have organized a Thursday morning event with Eric. Hurry up and get a spot while there are any left.

I have the honor of interviewing Eric for a second time in a few months–we was at the customer development event I put together in the fall with Future M, General Catalyst and Microsoft. What questions shall I ask him? Leave a comment here or @reply @simeons.

Posted in Uncategorized | Tagged , , , , | 1 Comment

Twilio forwarding and CallerID hack

I like Twilio. They’ve made programming voice fun, something it certainly wasn’t when Dialogic boards were the platform of choice. I’m using Twilio for a new service I’m working on. More on this in another post.

When you start playing with Twilio, a few common needs arise. For me, the first two were:

  • Forward a Twilio phone number to another phone number. In testing, I have to switch between lots of different numbers. Twilio uses Web hooks, i.e., maps phone and SMS events to HTTP requests. I found myself tweaking scripts a few times per day.
  • Registering a Twilio phone number for CallerID. Twilio wants to validate that you control the number you want to register for CallerID. Therefore, they give you a call and ask you to enter a random PIN. That’s not easy to do when the verification call to the Twilio number will result in an HTTP request to some app.

It was the problem of registering a CallerID for a Twilio number that led me to a simple hack that solved both problems. My idea was to forward the Twilio number to my cell phone and enter the PIN validation when I got the verification call. To make things a little easier, I made the forwarding endpoint accept the forwarding number as a parameter.

You use it like this:

http://simeonov.com/twilio/forward.php?to=12345678900

The link is live so feel free to point your Twilio numbers to it. Remember to enter the phone number with the country code.

The code is trivial:

<?php
    header("content-type: text/xml");
    echo "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n";
    if(!$to = $_REQUEST['to'])
        $to = "18005551212";
?>
<Response>
    <Dial>+<?php echo $to ?></Dial>
    <Say>The call failed or the remote party hung up. Goodbye.</Say>
</Response>

One of the Twilio numbers I set up for CallerID is going to be used for outbound calls only. What was going to happen when someone called it directly? That led to another quick Twilio hack–email me instead–which will greet callers and tell them to email you at a given address.

http://simeonov.com/twilio/email-me-instead.php?name=Twilio+Hacks+Incorporated&email=info,+at,+twilio+hacks+ink,+dot+com

Side note: when doing speech to text, you have to write the text in a way that helps the speech engine pronounce it correctly. Note the commas I added to insert short pauses and the mis-spelling of Inc as ink, which I found made the “k” sound a little stronger.

Go ahead, try this by calling (917) 300-0268.

Another “twivial” code snippet:

<?php
    header("content-type: text/xml");
    echo "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n";
    if(!$name = $_REQUEST['name'])
        $name = "";
    if(!$email = $_REQUEST['email'])
        $email = "the feedback address on our site";
?>
<Response>
    <Say voice="woman">Thank you for calling <?php echo $name ?>.</Say>
    <Pause length="1"/>
    <Say voice="woman">Please, email us at <?php echo $email ?>.</Say>
    <Pause length="2"/>
    <Say voice="woman">Goodbye.</Say>
</Response>

I wish Twilio did three things:

  1. Allow for static TwiML to be associated with a phone number. I’d love to just be able to enter some markup in a text box to handle simple cases like the ones above without having to deploy any server-side code.
  2. Automatically allowed us to set up CallerID on Twilio numbers we own. That’s just common sense.
  3. Allowed localhost targets using some type of automatic gateway software (in-page applet or browser plugin or Adobe AIR app). This will make testing so much easier.

Other than that, thanks, guys!

Posted in Web 2.0 | Tagged , , , | 16 Comments