Board of Directors Presentation 2007Q1 – Part 2/3

Continued from part 1 (vision)…

My next title is Chief Technology Officer. So let’s talk about technology.

First of all, we are unabashedly a technology-focused company. We make no apology for that, and we will continue to be a technology-focused company for as long we exist. We rely on our technological savvy to enable us to build the kind of compelling products we’re becoming known for. The novelty, reliability, simplicity, and sheer power of our products is dependent wholly on our technology.

We have a tagline on the bottom of our Myxer web pages that says “the technology is mVisible.” That’s a shorthand way of saying, yes, there’s a hell of a lot going on under the covers, but you don’t have to worry about that. We’ve welded the hood shut. Punch in your phone number and click “send to my phone” and we’ll do the rest. It’s invisible.

We’ve got a platform that can ingest content in virtually any existing audio, image, or video format, chew it up, and spit it out in a nice little package delivered to the doorstep of just about any phone on any carrier out there. We’ve got huge tracts of really cool technology that allow us to automatically identify the phone model of a requesting user and the carrier they’re with, we’ve got a database of phone characteristics that’s plugged into an automated feedback loop so that it stays constantly updated with new information, we have multiple messaging gateways giving us redundancy and flexibility, we basically have this whole content preparation and delivery thing down. That is soooo last year.

We leverage web services extensively in our platform, and intend to do so even more in the future. Already we depend on Amazon S3 for storage and backup, mBlox web services for delivering premium content, Google Maps for geocoding, RSS feeds from Blogger for our news capability, and I’m sure I left off a couple in there somewhere.

We believe that companies that embrace the loosely-coupled, scalable nature of cloud computing are going to have tremendous advantages over companies that fail to take advantage of them. And that advantage is coming a lot sooner than some people may think.

We work with what’s there, in terms of software. Forcing a local installation of software on a user’s PC is a definite disadvantage for any company, and requiring special software on the phone is about 10x worse. Aside from the logistics of actually developing the software and testing it on all supported platforms, there’s the huge hurdle of getting users to actually install it successfully. It’s just not worth it. See point #1.

In our short history, we’ve already created an impressive track record of innovation. Building on the core Myxer platform, we’ve developed innovative technologies like MyxerTags, allowing our users to effectively host their own ringtones from their website or MySpace profile page; MyxerCodes, allowing automatic shared use of the MYXER shortcode for mobile originated content purchases; dynamic delivery, providing the possibility for ultra-personalized content to be delivered through our system by our partners; and most recently MyxerMagic, which promises to make all web content just one click away from being mobile content.

We’re just now rolling out core support for video delivery, the technological challenges for which are mainly architectural (spreading the CPU load efficiently, storing and caching files, etc.) in nature rather than innovative. I expect the next jaw-dropping technological advancement we’ll make is when we delivery the MyxerMagic + MyxerFlix technology that will let anyone with MyxerMagic send any video they see online directly to their mobile phone.

We’ve filed for patent protection with claims covering aspects such as the core architecture and the (really smart) way we harvest metadata about a song unknowingly contributed by one user and use it to improve the experience of subsequent users that use the same song. Most recently, we’ve crafted claims around the recent MyxerMagic and dynamic delivery inventions.

We have a regularly scheduled process with our IP legal team when we file provisional applications that cover our newest innovations, and convert previous provisional applications to full-fledged utility applications when appropriate.

So from a core technology point of view, we rock. We have probably one of the most robust mobile content delivery platforms available anywhere; we have unique technologies that take full advantage of the internet; and we have a group of awesome engineers churning out a lot of really cool stuff every day just waiting for the right time to spring out of the labs.

Inventions and the core technology that power our platform are only part of my concern as chief technology officer. High on my list of priorities is the scalability and reliability of our platform. Operating a website is serious business, especially when it gets the kind of traffic that Myxer is now getting.

Our website scaling plan is built to support the business model we’ve developed. The business model has conservative growth estimates that require the website to support ten times the current user load in the next year. That’s ten times as many visitors to the site, ten times as many ringtones delivered, ten times as many SMS messages sent, ten times as many files to store, ten times everything. And because the business plan estimates are conservative, we’re very likely to need even more capacity than that.

Late in the year, it became obvious that disk storage was a real bottleneck for us. We didn’t have enough local storage to hold onto the hundreds of gigabytes of files we needed to operate the site, and every time we needed to expand the amount of storage it required physical changes to our production facility. So, embracing the web, we built our own hierarchical file system based on Amazon’s S3 storage solution, to effectively give us infinite disk storage scalability at extremely reasonable rates. Following our commitment to automate everything automatable, this new system will basically operate on autopilot from now on; as local disk storage becomes sparse, files that haven’t been touched in a long time are simply deleted. If they are needed again in the future, they are retrieved from Amazon’s servers over the backbone without anyone ever knowing what happened. It’s really cool stuff.

What’s even cooler is that we built the system so that it can recover from a complete local disk failure, or even an obliteration of our production facility. If, for example, the great state of Texas (where our production facility is located) is swallowed up by a giant rabid sinkhole, we can bring up a new web server, point it at a backup database server, and the new web server’s local disk will be populated with all the files it needs from Amazon, as it needs them. We haven’t tested the bit about swallowing up the production facility yet, but the other stuff seems pretty solid.

Other scalability growing pains will come in the areas of page serving and transcoding CPU. The next few months will see us bringing up our web capacity with additional web servers and potentially a dedicated transcoding server or two to handle the CPU-intensive tasks of translating input media into the various output formats needed by our target devices. We’re also planning to mirror our front end web servers for extra capacity as well as fault tolerance.

Continued in Part 3 (Products)…