How bleeding $17k in 40 minutes led a startup to adopt ‘uncommon efficiency’

Photo credit: Weerapat Kiatdumrong / 123RF

In 2012, Pocketmath was only a pre-funding company with a small engineering team. To realize the dream of real-time bidding (RTB) and be commercially viable, we had to do things differently.

For a self-serve mobile advertising platform like us, we needed as many impression opportunities as the next guy—driving down cost-per-opportunity-analyzed without sacrificing capabilities. Moreover, our data volume was comparable to the likes of Facebook and Google‘s. Considering our minimal funding, success would only come with efficiency.

We then pursued a path we coined “uncommon efficiency.” We had to precisely match our resources with opportunities to maximize impact. We had to engineer opportunities for our resources to do the most good.

Navigating the fog

Let’s look at the beginning of our business. In 2012, while many people tried to build RTB engines, perhaps more scoffed at the idea. Indeed, many capable engineers turned away from building such systems. After all, like any computerized trading system, there is a risk—bugs or errors in trading that cost real money.

We experienced the dangers first hand in 2013 when we disabled safeties to see if we could improve volume and lessen latencies. Faulty code caused an order to target the entire US without limits. We bled US$17,000 in about 40 minutes. Fortunately, the systems were still in a low volume configuration for beta testing. Had that error occurred today, it could have been a million-dollar lesson.

We also faced unique challenges as one of the industry’s first self-service demand-side platform (DSP). Self-service systems need to do more with fewer user interactions—the more that goes on under the covers, the easier to use the platform becomes. This requires engineers to build more automation, more complexity, and more capability.

Every major engineering decision is a tradeoff between safety and capability. Thus, we implemented an agile development process that tolerates and corrects mistakes. Furthermore, we complemented our process by building layers of automated safety to reduce catastrophic errors and mitigate their effects. Those early times shaped us.

So, what is uncommon efficiency?

By our definition, uncommon efficiency begins with the idea that to survive and thrive, we need to do more with less. When we broke past a barrier, we often found that the impact of our unusual solution significantly outstripped conventional approaches. Breaking a barrier often opened opportunities larger than anyone expected.

The gains were not just in technology, but surprisingly also in management and in the use of that technology. Eventually, uncommon efficiency permeated every aspect of our culture, allowing us to derive benefits from smaller teams that did more.

As we came to embrace this idea, we also learned when to balance the old ways of thinking with the new. While innovation appears glamorous, it is yet another tool. We would learn by fire when, where, and how to mix unbridled innovation, well-established practices, and the fickle (but ever important) in-between.

Fruits of a new balance

By continuously evolving, we see the fruits of uncommon efficiency through several market benefits:

Democratic access: Every campaign, big or small, receives the same chance to bid on every impression opportunity. Because there are fewer needs to prioritize processing power, all have equal access to the market.

Better real-time decisions: More computational effort lands on sophisticated tasks that improve decisions. With fewer milliseconds on basic plumbing, more time goes to complex computations, improved machine learning, and retrieving more information.