Some well worn advice for any startup

by John Dietz of Adometry

When we started our company last year, we got a fair amount of advice, and most of it we even asked for.  Among the usual stuff like “Build a business, not a product” and “Everything takes longer than you think it will”, we also heard the standard “Get to market as fast as you can, even with a limited feature set.” We knew that we didn’t have all the answers, so we’ve appreciated the advice and help we’ve gotten from a number of sources, notably adjusting our development schedule to get to market as fast as we could.

Based on the idea of getting to market quickly, we had a UI prototype complete that we showed to as many people as possible, potential customers (advertisers and agencies), related companies (various publishers), other technology companies, and perhaps even some competitors.  Our goal here was to get feedback to validate or evolve the direction of the product and business we were building.  We followed that quickly with a functional beta product while continually getting feedback from our customer base.

Of course to get to this point quickly, like a lot of startups we took shortcuts. We chose what our priorities would be (scale, validity of data), but left some of the detail work for later.  The architecture isn’t necessarily what we want to end up with, but we wanted to spend our early development efforts proving we could collect and analyze the data we were pitching.

Then one day it happened.  We’d been chugging along happily for a few months with some small beta customers, when we finally got the signed contract from a very large Fortune 100 company that was very interested in using our system to show the value and efficiency of their online advertising purchase. The same afternoon we received the signed contract we had the email outlining the campaign they wanted to run. It wasn’t a huge campaign in the overall scheme of things, when I was at Disney we would easily serve a billion ads per day, but this campaign would represent a magnitude more traffic than we were seeing with our earlier betas. It was go time, or perhaps go go time since a couple of days later we got agreement from our next major customer who would generate for us another large volume of requests.

As everyone knows, success is not a bad problem to have, but our engineers and I worked hard and late for the next several days scaling out our Amazon EC2 tiers and doing some extra load testing to make sure we could handle the traffic.  Because we have a good relationship with these customers, we convinced them to do incremental campaign analysis, just as an extra precaution.  Our focus at this point was entirely on our customer experience. Whatever happened on the back end, or whatever extra effort we put in, our customers needed to see and trust the data we were providing.

To prepare for the traffic we took several steps:

• Moved key files to a CDN (Content Delivery Network) for quick delivery
• Validated multi-tiered environment with load balancers and failover for most important services
• Generated traffic and data sizing projections
• Performed load testing
• Server resource monitoring

At 2 PM on a recent Monday, the fire hose opened and we watched carefully.  Things looked good and traffic was climbing. Our servers were running fine and data was showing up in our UI with about a 3 minute lag from real time.  We were watching error logs, server utilization, and log sizes. At 2:32 one of our logging servers failed, unfortunately due to some processes left running on that box from when we ran the entire system on that box, but the failover process worked perfectly and we lost no data (I would rather have not had the failure, but it was a nice production test of our failover ability).

We quickly found another bug in the data parsing and were able to resolve in quickly, again with no data loss. In all, we spent the next several hours watching, tweaking, and on edge. This time may be the most exciting time for a startup.

The system is still running just fine, and we are projecting traffic based on this data for bringing on the rest of this campaign, and for the start of our second big customer, scheduled to go online shortly.

A couple of last thoughts and learnings:

Advice about getting to market fast is right on. The feedback we got from early customers was fantastic and has helped us build a better product.  Had we gone heads down for 12 months to build what we thought was the perfect product would have likely missed the mark

It’s okay to take shortcuts, but understand your core value, and don’t skimp in those areas.  Had we not built for scale, we would have had more problems and might have lost data

Design for system failure. Although we didn’t expect things to fail, we planned for it and I’m glad we did when one of our logging servers locked up.

We were fortunate to have some very good data to use when forecasting traffic, and we spent a lot of time forecasting optimistically and pessimistically to make sure we understood what would happen in each case.

Don’t be afraid of success. When we first got that contract back quickly followed by the size of the initial campaign, I’ll admit to a short period of panic. I still wanted to call this a beta, I knew there were going to be problems. Fortunately we had planned well and focused on what we knew was important.

John Dietz (LinkedIn profile) is a co-founder of Adometry, a startup focused on online advertising metrics and writes about online advertising metrics atblog.adometry.com.