Doing too much will kill you
One of the first really important lessons we’ve learned while developing StudioTalker is that focus is what makes for a successful startup business. We’ve spent hundreds of hours re-inventing the wheel, trying to create our own top-to-bottom infrastructure in-house, and it’s been killing us.
When I first had the idea for StudioTalker, I thought it would be simple. A month (maybe six weeks) of coding by myself and it would all be easy. I’d have a sparkling, all-singing all-dancing, and most importantly fully functioning product that I could start doing real world tests on.
Eleven weeks in and we’re only just starting to make real progress. I realise now, that not only were my estimates and expectations totally nonsensical, but that my approach was too.
StudioTalker’s value as a product doesn’t lie in the low-level mundane infrastructure that I wasted (as in pointless, will never get it back) approximately a month trying to construct. Given another month, maybe two, I’d probably get that down; but that’s time that I just don’t have.
As a tech startup, the number one priority at all times must be to ship. It’s a race; only in this one, the tortoise doesn’t stand much of a chance. The best way to win Formula 1 is to reduce weight, improve handling and streamline the car. All of these things apply directly in business.
It’s a shame that it required the loss of a month of productivity to realise that, but it’s a learning curve. I never claimed to know everything before I started (even if my self-expectation required that), nor to have a crystal ball.
My approach is, unashamedly, to make it up as I go along. In doing so, I’ve learned a very important lesson the hard way. Hopefully in sharing this, you may avoid the same mistake and reserve more time for making others, for that is the nature of evolution.
We’re Hiring
StudioTalker is looking for two temporary full-time engineering freelancers to work on our product for approximately the next month.
We’re looking for one person familiar with Ruby/Rails and one with experience of Cocoa/Objective-C.
This is an ideal opportunity for a Computer Science student/recent graduate who’s in need of some portfolio material or just a challenge.
Budget is modest but fair. If you think you fit the bill, get in touch via email (ben@studiotalker.com) with details of relevant experience and sample code you have written (preferably a github profile or similar).
Telephony API Providers and Why They Suck (WTS)
So on the road of developing the StudioTalker product, we recently met a fork. The media backend for the app is easy, we can handle that just fine. Signalling, on the other hand, is a lot of work. What do you do when something is a lot of work? You outsource it….
Except that’s tricky. The vast majority of “Cloud Telephony” products, which are essentially large signalling and API farms, are based on the same pretence - a simple call flow, be it basic playback, DTMF or voice control and maybe an IVR, and then hangup. That’s all well and good if you’re doing appointment reminders, but StudioTalker is more complicated than that.
So then we found Ribbit. Ribbit looks cool, until you realise that they don’t like SIP endpoints and they do like Flash. Oh dear.
Next up, onSIP. US only. Fail!
Unfortunately, this leaves us with few other options, so it looks like we’ll be taking the other route and doing this ourselves; this is gonna take time, but we may just sell our byproduct…
Old Operating Systems
So yesterday I encountered the first major compatibility issue in StudioTalker development - Windows XP.
SSL is an integral part of any web application which transmits sensitive data between the browser and back-end, and StudioTalker does plenty of that. Traditionally, the SSL specification requires a dedicated IP per certificate, and we all know IPv4 is fast running out. Unfortunately in our case (and for many others, see http://docs.heroku.com/ssl), a dedicated IP is not cost effective for now, and so we must employ some technical smarts, namely the SNI extension. This allows the use of SSL in shared hosting environments, such as Heroku.
But there’s a catch. IE, Chrome and Safari on Windows XP don’t support SNI (all modern browsers on newer operating systems do, with the exception of Konqueror). Now, Windows XP was released in October 2001. That makes it almost nine years old. There have been two major Windows releases in that time.
It’s impossible to please everyone, and that’s why we’ve decided not to try. Using StudioTalker on Windows XP is therefore not supported. As it stands, it’s unlikely IE will be supported on any platform. We firmly believe that legacy compatibility is an unreasonable expectation and so if you wish to use StudioTalker, we suggest upgrading from Windows XP and using a modern browser (we love WebKit, so Chrome or Safari are fine by us).
Hopefully we can play a very small part in moving the world forward.
Well wasn’t that nonsense. We’re already accepting beta signups. What I meant to say was that we’ll soon be actively promoting our beta and seeking test users. Hold onto your hats.
StudioTalker progress is steady and respectable. We’ll be open for beta invites soon, along with a blog post about what we’ve been up to!
Is this you? Get in touch!
StudioTalker is now accepting beta signups for when we’re ready!