1. Library
  2. Arrow Icon
  3. From YC to Liquidity: Behind the Curtain
  • Product
AUG 19, 2014 - 67 MIN

From YC to Liquidity: Behind the Curtain


As Co-founder and Chief Scientist of Cloudant, Mike Miller started database-as-a-service Cloudant after recognizing the need to analyze petabyte datasets with CERN’s Large Hadron Collider project. Since then, his role includes developing the company’s technical vision and managing long-term product R&D. Miller joins Heavybit members to present the successes and failures of his company’s journey from YCombinator to its 2014 acquisition by IBM.

  • Introduction
    • What is Cloudant?
    • Where we came from
    • Y-Combinator
    • What defined the company
    • Engaging with Customers
  • Lessons Learned
    • Your Market Matters
    • Revenue vs. Ubiquity: Choose One
    • Don't be Stealth
    • Don't Have Interview & Hiring Hubris
    • It's all about developer experience
    • Don't default to developer experience
    • Don't wait too long to hire and external CEO
    • Know the product, know the business
    • What are you maximizing?
    • Win the Air War, Live in Public
    • Choose your investors wisely
    • Startups are hard, trust and communcation are critical
    • Always put your users first
  • Q&A
Download slides

Thanks. I'm glad everybody is here. My name is Mike Miller. I was actually not the founding CEO. I avoided CEO at all costs. One of my co-founders was the CEO. I was the chief scientist, but we all worked together to go on what was a pretty long journey.

I'm going to tell you a little bit about, just real quick, what Cloudant is to give you an introduction and kind of lens through which I see this. Then I'm going to focus on the things that we learned along the way. Hopefully, everybody in this room has already learned those things, but for some reason we didn't know any of them. I'm going to try to estimate the impact that they had on stretching out the time it took us to do things or the overall impact of the company at some scale. Then I think we have time for questions afterwards.

Real quick just to give you a brief introduction to Cloudant, we came at this from a kind of nonstandard approach. My co-founders and I are scientists. We did particle physics at Brookhaven National Lab and CERN in Geneva, Switzerland and we were very comfortable swimming in data.

We were kind of versed in the problem of trying to make a whole bunch of distributed commodity resources behave as a single entity, extract that away, make that easy for the end user. Th en we could actually do what our day jobs were, which were to do the science. But that got us onto something that we realized eventually was going to be a thing.

I'll just give you a quick two-minute overview of Cloudant so you can understand the bias that I bring to this. Cloudant is a database as a service. We can say that now cleanly after seven years. It took us awhile to get there, but the hope is that you go and you sign-up. We give you your username.cloudant.com and that magically resolves to resources on 35 data centers on the globe. We're like an Akamai for your database. Instead of doing static content everywhere and making your problems of scale and latency go away, we do that for your database. We do it through one, now two, open source APIs and that's really the promise. It does the things that you expect a database to do, if you're building web applications.

I didn't realize until two years ago that we simply solved the problem of application state, which is a stumbling block. We came into this with some grand ambitions of all the things we were going to do and all the many problems we were going to solve. Then it was just a constant process of saying, "No, no, no" and trying to get down to the few things that we did which were very differentiating. I'll walk you through that. But if you're building an application, this is basically the Backend in a Box, JSON documents, primary index, secondary indexes of different types, geospatial and search.

The whole goal here is to help application builders or application developers do things more quickly, but we tended to focus on scale and big scale given our background.

This is the picture we like to show. You take little Cloudant logos and you place them, I think in 35 data centers now across multiple providers, and you magically connect it to username.cloudant.com. That can be as simple as a few servers if that's your choice or as many as several 100 in 35 data centers. We're on a variety of providers: Rackspace, SoftLayer, Joyent, Azure, AWS. That was one of the things that actually allowed a small company like us to learn quite a bit about how the whole business of cloud hosting and manage hosting works. We're starting to increase our buy with providers like that and suddenly a small company could be taken seriously by somebody with a billion-dollar revenue stream. It was a great chance for us to learn. We're just wrapping up a little bit about the company.

It's funny, I remember when we were coming out of YC and trying to raise our first round, they're like, "You've got to get a customer, and then you've got to get an enterprise customer. And when you have three enterprise customers, then you know you're making it." At the time of the acquisition — this is a year old slide, but I like to show it because we have a variety of different verticals covered here — at this point we have Fidelity and Novartis and all kinds of enterprise companies that I never thought would put their data in the cloud. But the reality is, this market is going so quickly that we were kind of swept along with it.

I love the fact that we still have Heroku as a partner here and Salesforce as a customer, mobile gaming. It just reminds me that when we were raising money people said, "Okay, database. What's it good for? "It's kind of like Unix. What's that good for? That's a hard question to answer, but everybody in this room knows it's fundamentally important.

You're doing something that really matters and so that was kind of the belief that I think steadied us through all those conversations.

Okay, so now I'm going to step into a little more behind the scenes and give you a feel for our company culture , where we came from and what we did. I hope that allows you to appreciate some of the things that I say later on. A brief history: These are embarrassing photos to show. I met my co-founders in 2004. That's me with all of the hair on the left side of the screen. I was fresh off my post-PhD soul quest, which I think is a requirement, six months in Nepal living in the Annapurna, building a wireless network and having a lot of fun. You can see I'm wearing not one, but two necklaces in this photo.

I came to MIT as a postdoc and I was exceptionally relaxed. I just remember feeling that I actually have only just achieved, again, recently, post acquisition which is kind of a feeling of quiet "I know who I am and what I'm doing right now" and some calm. I was lucky enough to help build a new research group that went from nobody to I think 25 people in the first two years. The first two people I recruited, who are up on the picture here, are my co-founders now, Adam Kocoloski on the far right and Alan Hoffman in the middle.

We were kind of a core of three folks that shared a big common history. We were Midwestern, we did physics but we also had philosophy degrees. We were interested in deep things and technology and just had a lot of fun together.

We worked together in the physics world for four years before we decided to start a company. We decided to start the company because our paths were going to part and we enjoyed working together so much that we decided "we have to do this." We have to take that chance.

I'll come back to that. But we did some fun things along the way.

By 2005, we were already slightly bored in our day jobs and realized that to do the big science, and this is a ten billion dollar project over 20 years, to build the Large Hadron Collider, probably the greatest thing that mankind has built — a highly technical version of the Panama Canal-type of project. There was no malaria involved, but there were equally technical challenges. We were very versed in building the data systems around that; and that meant harnessing almost 200 global data centers in a populace of 20,000 demanding grad students that wanted to run their incredible crappy C++ code over ten petabytes of data and get an answer back in the next few minutes. Why not? We should be able to do that.

We had to do inventive things along the way and this photo is actually the first cluster we built. That's a five terabyte, I think, serially RAID 0 LaCie drive which was our file server when we got all of the MIT departments that had a Mac desktop to donate them into our Xgrid. We did opportunistic computing on that because we didn't have enough money to build a proper data center. Eventually this turned into a grant and we built a petabyte scale facility with 2,000 cores, in 2007, which was a lot back then. But, it was much more fun to do these things on a shoestring when they were heavily funded, and I think that's been a theme of our company along the way.

Then we decided to start a company so that we could work together and to be blunt, we really didn't know what we were going to do. We knew that we liked data. We always brought ideas to lunch every single day, but I think it became very serious when I went home in December 2007. I was at Christmas break with my now ex and her mother, and she threw down this Businessweek article which she had picked up at the dentist's office or something. It had a picture of Chris Bisciglia on the cover and it said, "Google and the Wisdom of the Clouds."

I had no idea what cloud computing was. I'd never heard of Hadoop or Chris Bisciglia, but she said "It sounds like what you do, lots of computers, a lot of data. They call the data big and it happens in the cloud." I was like, "That's total bullshit." I open it up, and I was like, "This is exactly what we do."

What hit me was that the problems we were trying to solve, we had thought were only relevant to science and engineering and we had this hubris that we carried along that we were working on the biggest problems. We had the most challenging problems of scale and what we were working on was by far the most important.

What I realized in that one article was that these ideas were suddenly relevant, that the world of science was being passed by the world of web and social media and all kinds of new companies then. That was a far more efficient market and the challenges of scale and the relevance of what you were doing and the impact that you could have were huge there.

We started a company and then we just kind of sat around. It was like that great British stunt band. But we were lucky enough to start the company by getting into Y Combinator. Back then Y Combinator was in Boston in the summertimes, so we didn't even have to quit our day jobs. We did almost everything that Paul Graham told us not to do. We stayed on the east coast, we kept our day jobs, we didn't spend any of the money he gave us, but we did focus on getting users early. This was a huge moment for us.

None of the people here actually did YC, right? You were lucky enough to jump straight into something post? Y Combinator for us was great. It's probably like a few minutes with Obama. It's hope and optimism and then network and funding. We were kind of three punkish scientists with no real products. We knew that there was something exciting happening in whatever "cloud" was.

We kind of had this thesis that the general parts of the computer were going to be extracted into services that you rented from somebody else because it just allowed you to go faster. And to this day we don't own anything but laptops. We're one of the early companies that did this.

A long the way I think one of the first talks I saw was from the Heroku founders, James and the rest of gang. They were one of the first companies to take venture money; maybe Sam Altman had done it from Loopt before. I'm not sure. At that point everybody was incredibly leery of venture money in this space and it was all about angel. I was like, "Boy, that sounds hard. Like, I've got to meet ten people instead of one." We were lucky enough to come out as a few folks, and a prototype, raise some money. I'm going to talk about in detail what happened.

We weren't shopping the company, but in February or March we had a fast and furious blitzkrieg from IBM and ended up with a very clean exit for everybody involved. I can't go into the details, but everybody won. The initial investors had a great exit from a venture perspective and even the folks that came in on our Series B and then exited nine months later were extremely happy with what happened. The company and the product are off and running. IBM has this thing running everywhere. I went to a conference three weeks after the acquisition, there's Cloudant running on a car, it's back in their mobile service, it's at their core of their Internet of Things, it's being sold into the enterprise.

Just an aside, if you sell a company the price that somebody should pay for it depends on who you're selling it to because its value really does as well. I hadn't fully realized that.

So to project this back onto the YC idea — Has anybody seen this photo? I doubt it's still up, but Paul Graham scratched this on the wall one time and it pretty much defines our company. I'm going to go into it in more detail, but I think the things that are fun are the Techcrunch of initiation. Everybody was always building to launch back then with not much thought to what happens after launch. So you launch, you get some publicity. We actually kind of delayed that for reasons I'll talk about. Then it kind of wears off and then the reality sinks in.

You're out of your incubator program. You've maybe raised a little bit of money but you have a clock going in your head now about when that money is going to run out and then it starts to get challenging. Then there are periods, th ere are lots and lots of chances where you could quit and success is a slog — I see these guys laughing — a nd you're like the "hot company." You're all over the news which is great, but the reality is even somebody that's killing it all day long every day has plenty of doubt about what they're doing.

One of the things that I'll come back to at the very end is it's funny for me now to stand back and look at where we ended and where this product and this company will go, and compare that to our initial ideas and the mission because you make a lot of optimizations along the way and they take you to a place that you may not expect. I think that's a message that's been getting a little more press lately that I like. But eventually we found something that works. We tried a lot of things and I'll go into more detail, I'm going to come back to this.

I'll just note one thing I only noticed in putting this together. There's the acquisition liquidity, your some type of exit, they call it, depending on how you want to do that.

Then there's an upside of a buyer and then this curve turns over. I'm not actually sure why it turns over. I'll have to find out in some more detail. We haven't seen that point, yet. We're still where ev erything is up into the right.

I just want to talk about a few things that really defined us as a company. One of the first things, we raised our venture round in the fall of 2008. That was not an easy time to do it. The market had crashed and I was lucky enough we had some good opportunities early on, but decided that we didn't want to puntz on finishing up our careers at MIT. My co-founders were within a year of their PhD. A "year" turned out to be quite more with many leaves. But we weren't quite ready to do that yet and if we were, who knows maybe we'd be the next MongoDB. I doubt it because we had so many things to figure out at that time. That would have been our first rodeo.

But very early we got this office which was a total dive and I absolutely loved it. It defined us as a hungry company. It was ours and it was all we could afford. This is my co-founder holding his first daughter in his hands and things got very real. When you hire people, it's like, "Okay we hired some people, but they've got significant others and those others have a job." And then my co-founder had a daughter and it's like, "Wow, this is it. Like, Chloe is on the payroll."

It was already in Massachusetts, we were doing business in Boston and we came out of MIT, so everybody had to have health care right off the bat. It was a very real company right away even though we didn't necessarily know what our product was or quite what our market was or how we were going to pitch it. There were real people involved and the bottom line really mattered. We did not have a whole lot of fun spending money in the beginning and our founding CEO was brilliant in not letting us spend money on anything.

We more or less stumbled into running a service instead of building software and running it, writing it and licensing it. That is the brilliance of our products, but we had no idea what we were biting off.

I had run big systems before. I was responsible for the Tier 0 System at CERN for one of two big experiments. Massive, incredibly well-funded, ten petabytes of disk, 100 petabytes of tape, anything you wanted. But it was a batch processing system. If somebody's job died or a batch queue is down for a few hours, it was okay. The machine had to be on, you could still buffer the data for a day until you got your stuff together. But with a database that backs a web application, if it's down, people can't buy or sell things. People can't log onto the system. The bar is exceptionally high and that hit home immediately. That is where everything is going. I have no doubt in my mind that is the right business to build. It took me awhile to realize that — but the impact on your company culture.

T his is a plot I made. I had to jump on the phone with then the head of EBS. This is the reason why you don't RAID 0 8 EBS volumes together because they're not real disks. At that point Y Combinator had gotten us a hotline, one of the few things they did. They had gotten us a hotline to the head of EBS, which was a newly launched product and we could say, "Hey, one of these is not like the other. Here's the picture that shows it." This was during my co-founder's wedding. I'm in the back, I'm closing tickets, I've got an angry customer. It really hit home what a service center industry was really about as well as dealing with the customers.

This is one of our early employees and I remember writing this letter, "Dear. . .," I'll keep his name out of it, "please refrain from using the term 'douche-nozzle' when addressing our customers in public." And he's right. Tou love your customers, but not all of them. But anybody that's using your service is somebody that you want to engage with and it's always tough. You've got the back channel on IRC hear something like, "What is going on with this conversation? I don't understand it." But that's what it means to run a service industry.

Taking all of that and projecting it onto PG's trajectory of the company, when I look at it — we built Cloudant 2008/2009 — 2008 was totally lost to just YC, some ideas.

We pitched a search company to YC, that's what we did. They're like "You guys know data, big systems, literally. Go be a pain in the ass of Amazon because they're the new IBM." I think those were PG's words and he was totally right.

We launched a service in October of that year, I think, and we got 600 sign-ups in the first day. That's probably still a record for cloud sign-ups in one day and a testament to what a good launch on Hacker News will do. Then things got quiet and that's when we built real technology, that's where the challenges really hit, that's where we made incredible mistakes that I can't believe we survived from a business standpoint. But, we didn't run out of money and we had incredible support. Then we finally started to find something that people liked.

When I look at our company and I think about the lessons — I wanted to make this a little more quantitative than I was able to pull off given the fact that I'm completely sleep deprived; I've got 13 week old twins, so my wife and I are just trying to survive at this point. This is more of a beginning of an analysis than a closed one, but if I think about the things that we learnt, everything that we learned either stretched this curve too far to the right or lowered some portion of it, that's it. You want everything to go up and to the right as quickly as possible. I'm going to try to give you some rough estimates of how I think these things impacted us as we go along and hopefully you know these already like I said. I'm a first principles guy and it takes me a long time for things to sink in.

I will note that we knew we had things figured out before investors realized that we had things figured out. I remember a point where I was like, "Alright, it may not be easy to raise money, but we've got to raise this next bridge to get to growth because we've got it figured out."

We've got people that will pay us five grand a month minimum in recurring revenue. There's a business here. We had spent zero dollars on marketing. If you can do that —there was something there.

I'll just draw your attention. June 2008 we started Y Combinator Incorporated, raised money in December 2008, January 2009 and then actually ended up selling in 2014. That was absolutely the right decision, it absolutely went to the right place, I think, one of the few companies that can rise up and challenge itself to confront Amazon going forward. It's a long period. Initially we had thought, "Eh, these YC companies they get in $20,000, they sell for $500,000 coming out of demo a day." That's not what happens. You've got to be committed to it for 5-10 years or more depending on what you like.

Let's turn the corner to Lessons Learned. These aren't in a highly curated order. It's a little hard for me to figure out, do I put them in the order of when we learned them or when they started or when we should have known it. I'm just going to try to kind of prioritize those with the things that were important up front and also at the end.

N Number one: Choose a market. We really fell into this one. We bounced around a little bit. We weren't sure whether to call ourselves a database company or a NoSQL company. A lot of that had to do with how we packaged the product and offered it. But in the end this is something that is actually very quantifiable and probably the easiest to quantify.

Investors are going to put you in one of these buckets anyway, so it's for you to choose.

In our case we were in a market that took off a lot faster than I thought it would — cloud services. Back then people were talking about infrastructure or platform or something like that, but in my mind it was just a stack. People built applications, the application is a stack and the great thing was that mobile and big data kind of had broken that stack, so it was being reinvented. As pragmatically it was companies like you guys who are not highly funded to start, but you have a problem. You don't have the money to buy a solution so you build a solution or incorporate an open source technology. That was really good for us.

In this case, identifying with cloud over database is almost like a five to one, if you look at the market growth overall. We decided that new markets are great. Salespeople hate new markets and maybe for good reason because it's not the easiest sale, but in our case we're not trying to displace Oracle for all the things you have running, your SAP in your existing database warehouse. Our fundamental thesis is that all of that stuff stays and maybe degrades at a few percent year over year. Then there's this new giant thing that's growing at 30% year over year, which six years from now will eclipse all of IBM's existing business. And that's all brand new stuff.

You don't have to get the whole business. You don't have to get the whole application. You just have to get a feature or a button in an app and that's your foothold.

If you do well, that's a reference architecture and then you scale that. It's very much the sales horse/ Trojan horse model that's been very good to us. f you're in the good market, you get swept downstream and that's probably not news to anybody.

It's interesting for me to step back; we sponsored a conference in 2009 called NoSQL East. It was maybe the first conference that had NoSQL in the name. At that point, Tengine was an open source platform company and not MongoDB. Hadoop was like brand new. Somebody named Kevin Weil who was a recovering string theorist was talking about it. I think he may be their chief revenue officer now or something, really nice guy. He was like 25 at the time. Basho maker of Riak was the Salesforce.com plug-in company. It was a very different time. If I look from then to now, this is a big business just NoSQL alone. It's incredible.

It was really fun to be a part of a market like that where I never thought if engineers or one of our competitors leave it would be printed up in the Register and that one of our competitors would have a 1.2 billion dollar valuation. This was quite awhile ago. So it's fascinating to me to see how quickly that market can go, but it took us until 2014 to realize that this is like the battle on the rear flank. The real battle is who we lose sales to and that's like the new IBM in this space. Nobody gets fired for using Amazon. Nobody gets fired for choosing Amazon. They are a total juggernaut. I live in Seattle and their doubling time right now is like 12-18 months in terms of footprint in the city. It's very soon going to be renamed to Amazonia or something. I'm not sure. But it's incredible, it's absolutely incredible. Their web services branch is predicted to maybe take their cloud services greater than their consumer market.

Market is good, but it definitely forced our hand a t the end. It was very hard to be a small independent company that was running lean on a grand total of 18 million dollars of venture funding set six years into it. That's tough when you've got Amazon down the street. That's the good and the bad of that.

Here's another mistake or lesson learned. I didn't ever think about this until I saw Bill — I'm going to do terribly with his last name, Lapcevic? - Lapcevic gave a talk here about a year ago and he's in charge of partnerships. His general thesis is that partnerships are like the exponents on your overall growth and then he talked about how he grew that in New Relic which is a company that I think did exceptionally well. I realized at the time as he was saying it that his overall thesis and his framework was really the model that I had been missing in trying to grow the company for all decisions.

We didn't actually have a working model for any decision that we were going to make, whether it was a product decision or a strategy decision or a hiring decision or where we were going to spend our money. It was very useful for me to see this most basic model and then just collapse all problems onto that. His basic thesis is that your whole business is a plot.

All choices are ubiquity on one axis and revenue on the other, and that anything you're going to do, you project onto that.

In partnership speak, they actually take their potential partnerships or the existing ones and they quarterly put a dot on that graph and they look at the trajectories and measure the velocity and do some pretty clever things.

When I think back to the decisions we made about how we packaged the product, what we charge for it, how much we invest in marketing, that's all on one of those two axes. As a company we did exceptionally well on revenue, exceptionally well. I'm sure we dominate the dollars earned per venture dollar in NoSQL, properly normalized. Partially we stumbled into something. We also we had a great CEO — I just met one of his mentors here tonight — who came in and really helped us understand what our business was and then sell the heck out of it, which was great too. But, I wish we had this model earlier on because it would have made a lot of decisions easier.

Here's another mistake we made. We were stealthy and I don't know why. I can't even understand it. I think it was mostly because we were just cautious. We're a bunch of physicists. Physicists like to perseverate over papers until, "Oh, what's the final not just statistical but systematic, uncertainty and it's asymmetric and how wrong could you be?" Very embarrassed of being wrong. We didn't understand that the market and the community that we're coming into was incredibly forgiving and accepting as well as just hungry for new things and excitement and information.

If you could be the bringer of good news with a blog post or story about EBSi operates, it's a famous story from Heroku, you're an expert suddenly, like that.

We should have talked about our idea to everyone. We should have blogged about it everywhere. We should have done everything we could've to get free marketing out of that.

Yeah, there will always be some people that can point out the parts of your product that aren't there yet, and that's okay a s long as you're honest about it. If I think about how much of a mistake this was, this was probably only a 2x mistake. I think it's vertical, but it happened very early. You take x valuation at the point of liquidity and I think it's a factor of two on that, probably.

T here are examples of companies that are at the opposite of stealth that I'll talk about, that have done just a great job I think of building up community and product around that by doing a lot of talking out in front of the products and really driving community overall. I'm going to come back to that one in a second. But, had I had a working model, stealth just takes you backwards on the ubiquity axis. It's not the right choice. We had a great demo. We had a great launch the first day, 600 sign-ups the first day, but what we care about is the integral of that curve. We just want to get it going as quickly as we can and let it grow and have something to poke at and have something to measure.

I would highly recommend against doing anything stealthy. This was a mistake that we got over pretty quickly.

Getting some money, getting a chance to hire people for the first time was incredibly exciting and we took ourselves very seriously. You go on the YC founder's list then you have a chance to talk to all the founders about your point and backwards. How do you hire people? What are the interview drills you do? Elaborate systems and flying people in and spend long times with them and going through this rubric and charting things and plotting them. None of that correlated with success in whom we hired.

Then we kind of realized early on "let's just double." I was in a fraternity in college and they're like, "your one job is to replace yourself before you leave." That's all you have to do from a recruiting perspective. You don't have to get 30 new people. You have to get one. With a company you're growing and you've got to grow exponentially, so you've got to double. But if you think about it, we were right around 100 people total, 80 if you don't count full-time consultants at the time our acquisition. It's only a handful of doubling times. That doubling time exponent was great and we decided what worked very well for us was to just hire a network.

If you look around, every single one of you has two people that you've worked with in the past that you'd love to work with again, I bet. You don't have to have the perfect job for them. In the end, I absolutely lobbied against writing job specs. I just wanted to find bright people that we wanted to have in the room and granted maybe that's selective for a monoculture. Probably. We have a very male heavy company which is something I wish we could have changed, but it's starting to evolve now. But it just made it so much less risky than posting a job and responding to a bunch of strangers and trying to devise the perfect test.

Work your networks; that's what you do as an entrepreneur.

Next, and probably most painful. I love technology. I'm a technologist. I think that most decisions should be made from a technology standpoint when adopting something, a solution. This gentleman who is a great white hat competitor, Dwight Merriman, very skilled, stood up at the NoSQL Now Conference in 2009 and said, "MongoDB, people like it. I wouldn't necessarily put data in there that you really care about, but it's fast and we're trying to make it easy to use." He's like, "That's what really matters." And I was like, "That's a terrible idea, Mr. Merrimen. People are going to choose based on where you stand in CAP theorem space and all these academic things." And that's not true. It's all about the developer experience.

Only later we realized what we sell is developer time, it's incredibly precious. I'll come back to why that is. It's all about the user experience. Right now we market to developers. We build things for builders. I think everybody in Heavybit subscribes to that thesis overall. This is really a tough one and Cloudant continues to make this mistake quarter over quarter, year over year. Our product is just too hard to use and given the choice, we'll always hire a backend engineer over a designer or over somebody that writes a really slick python cline library.

Only now are we slowly changing that tide and have painfully realized that especially as you move into the bell curve of developers, folks who may not be so eager to adopt the newest of technologies based on something they wrote in an ACM journal article, this really stings you. I don't know, this is probably a 50% penalty, but it's hit us year over year. I know that many, many of my compatriots in that NoSQL founding class from other companies feel like they've made the same mistake. I think it's one of the reasons that in some very deep pockets that's made MongoDB quite a winner. Ubiquity, clearly on the ubiquity axis as well. This one hits both directions.

Closed source. Man, we thought we had magic algorithms and we didn't want anybody to be able to get their hands on those. In the end we were acquired with zero patents because we had finally realized.

The watershed moment in our company was when we just got bored and decided to open source some stuff.

We're like, "Hey, we've got a cluster thing that speaks CouchDB." It's like CouchDB API on top of Dynamo and it's not actually what we run in production, but it's something that we can open source, but we keep all the best stuff back. And we did that. It was like a watershed moment for the company.

Suddenly we got incredible developer interest, started signing contracts and it was great. I have no idea how much this set us back, but I'll state that we are very close, just watch the news, pushing very hard to do everything in the open source. Developers, it's all about developers. What do developers love? They love open source. As great as technology can be, we use things in our stack every day that are subpar technology and things that existed well over a decade ago. We use Hadoop when there are incredible solutions in finance for distributed computing or high energy physics or high performance computing, but there's this massive community of developers behind Hadoop. It is for better or worse the thing that will be in the enterprise for a long time and it will evolve to something radically different than it is now because of that community. This is like multiple ways that this can sting you.

As a cloud service it's great because now I know exactly how I'll do my next company. Everything in the open source, all the software totally commoditized and free. It's all about how you package different open source projects together to make a unique service. Heroku was saying this in 2008, but it didn't get through my thick skull.

"Build a cloud service, it's not about the software, it's about how you run it as a service."

It took us a long time to learn that and that's a debate that we have within our new acquiring company every day, which is a fun one. Basho team did very well with this. It always stings me that we're a company of academics, we've got like 20 PhDs in the company of a small size and Riak owns the mindshare when it comes to academic distributed systems. The best people from Berkley, Stanford, MIT are coming to Ricon because that's where great conversations are happening. They did an incredible job and I think it was largely through their open source community.

We waited too long to hire an external CEO. We were good technologists and we knew what it took to get a company off the ground and to raise money, but we didn't really understand what our business was and we didn't really know how to grow it. It would have taken us a long time to learn that skill set. We decided as gearing up to raise a Series B that part of that would probably be realized by any new investor and so we could either wait to see who they dropped on us or we could go out and try and find somebody solid. We spent about six months trying to recruit somebody to come join our company that was like eight Bad News Bears developers and one designer; we were kind of a ragtag bunch. But we knew that we had people paying us and if we could get some money to continue growing the company, the product and find away to sell it consistently that would be a great business.

We were lucky enough to actually have one of our advisors, Derek Schoettle, who was diligencing candidates for us. We finally just said, "Hey, why don't you quit HP. Vertica has been acquired at this point." He worked at a Mike Stonebraker company, Vertica, which was acquired by HP for about half a billion dollars and we said, "Why don't you just come in and bring some of your best people from Vertica with us?" Eventually he did. He gave up a tremendous amount of money, I'm sure, and many people on the team did. But we had a great tech team and he had the core of a marketing and a sales and a support organization that could come with him and help us build the company side to our tech half. That was really important.

When I look at other companies, maybe you're lucky enough to be founded with a CEO that knows that. Or maybe your company is patient enough that the CEO can learn that. Maybe you have a Stanford MBA that hadn't originally. But it was taking us too long to learn these lessons and it was taking us too long to devise a business path and it was really harming the business. We thought we did it early.

Looking back I think it could have saved us 6 to 12 months in that desert — in the Valley of Despair as Paul Graham calls it — just because he came in and told us things that we already knew. But he did it in a different order kind of putting the whole picture together in a way that an advisor, board member, investor wasn't able to do. Just coming in and immersing yourself in the business, looking at everything that you have and be like, "Oh, people love this and they'll pay that much for it? Let's go. This is our business. Throw all the other stuff out." That was really a watershed moment for us and where we started to really ramp the business.

Along that line, we didn't really know what our product was and we didn't really know the business. These are kind of taking me into my closing thoughts on the negative things that we learned. We started off building a huge multi-tenant service. That's what we wanted to do. Everything was going to be multi-tenant, metered, pay as you go. Amazon's SimpleDB was a nice example, but we were going to do it at great scale and everybody comes in, pay. A total addressable market that would be huge if we get the typical developers spending 100,000 bucks a month on their credit card.

In the meantime, we had these three customers, two of them were in our Y Combinator class. One was local, then one we met at an Erlang conference. They're like, "Look dude, just stand up a cluster for me so I don't have to worry about it. I'll pay you five grand a month for three servers." N=3 redundancy. Basically, one machine, triplicate storage. We're like, "Fine, yeah we'll do that while we build." They paid us a lot of money month over month. That's a pretty good MRR. Meanwhile we're busy building products and features and all these other things and they're saying, "Look, just don't make me build it myself. Just make this something that I can forget about." Because that's what they really wanted.

The cost of not realizing that sooner is a little too painful for me to admit because this is really our greatest innovation of everything that we did in the company, the software we wrote, the systems we built.

This is the very first check we got and this company is out of business so I can show it. This company called Collecta was a real time search company they competed our first customer Scoopler which was a real time search company. Two brilliant fellows from Oxford did Y Combinator with us, they had the Twitter Firehose in perpetuity for free, before Twitter was a thing, in their contracts. They had all this data, but they were convinced that they had to build a search company on top of that where they could sell ads to what was presented to you in real time search. Their algorithms worked great in a hardcore machine learning running inside of Cloudant, but eventually they just kind of petered out.

Our second customer was also a real time search. It was their one competitor called Collecta from Boulder. But they were willing to pay us. It started as a grand the first month, but it basically went to five grand right after that. It was a price point that everybody could make contact with, "Oh, five by three physical servers from Rackspace or SoftLayer. I'm paying about a grand a month anyway, and I get software and service on top of that." It's great for them. It's one half to one third of the price of a fully loaded DBA. It's not a bad deal. They don't have to buy software, they don't have to pay anybody to run it or operate it and that's the whole point.

This is Kevin Wolf, one of my colleagues who runs our service delivery team now, an ex-trader from London. He says it every day, "Our product is our service. It's not features." That's a real challenge. You go to our product meetings, we have a tight iteration schedule and it's generally feature, feature, feature, feature, feature. We never really got that right and I'm not sure if we ever will. Hopefully, the next generation of service companies will just be like, "It's got to run a little bit better. It's got to be easier to use. No new features. Just make it easier for people to understand how to use it." Which is the number one thing we hear from people:

"Make the documentation perfect. Let me just jump into docs.cloudant.com and go swimming; and all the examples of how I can solve any problem I'm ever going to have, display it to me perfectly so I can always find it."

We have an API reference doc. We have a couple of examples, we have some cute interactive things in the browser, but we haven't got this right, yet. And if we had, our adoption curve would be far accelerated. So that's a chance everyone of you have. I'll just note that we took a painful path. We started with dedicated where people who were paying us, then we built something. We bounced briefly through multi-tenant so quickly that I even didn't write it here. Then we decided to box the software and sell it under a license and do on-prem support. A total debacle, especially behind random firewalls. We're like, "They're just computers, how hard can it be?" Wow.

Then we went back to full multi-tenant. This will be the huge market of developers, more consumerization. Then we went back to dedicated when Derek came in and was like, "Hey, you've got people paying you five grand a month to start and then they grow linearly and then you add them linearly, that's polynomial growth. That's perfect." We did that, now the conversation continues, "Eh, maybe we should back on-prem. Maybe we should go all multi-tenant." So, I wonder whether we will continue to look at this and be able to zero in on where the market is now.

That takes me to the last mistake which only now do I think I realize what our business is. We sold the company right on the cusp of having what I would call "figure it out". You run an equation where a dollar goes in and a second ticks off the clock and this is what comes out the other end. We were close. We knew the cost of lead capture. We had a pretty high opportunity close rate; one-third is very good in our space. That was coming into that dedicated channel where it's going to be 5, 10, 15K an MRR to start and then grow up from there. We were able to get enterprise tractions, so things were really cruising. But we were all focused on revenue.

We had great community success by aligning with open source projects early, being good contributors to those Apache CouchDB, Lucene, some geospatial stuff, HAProxy, a lot of things that got us out and talking to developers, our end users. Then we built a sales team, "Oh, those developers they don't have money to buy. They don't have buying authority. Why are we spending our time with them?"

We slowly just somehow edged out of spending all of our time talking to developers and in IRC and where developers are. That was a big mistake. Because what happens? Our funnel starts to dry up.

It doesn't dry up, but it's not growing linearly with the number of marketing dollars or sales dollars that you throw at it. That's what you need to have your business really growing. It started to empty out as we threw those resources at it and to me it's very clear. We had some technical debt that stung us on service delivery, not nearly as much as our competitors but that was a thing. But we had real community debt and that was overcome by a nice MRR line that was big and growing and an incredible team, which I'll close with.

So now I think I know what the equation is that we had to maximize, but we didn't quite have it figured out. We're getting there. This was our biggest mistake by far. We did great on the ground wars. One of my friends, Emil Eifrem, the co-founder of Neo4j likes to say, "You guys are doing great on the ground war. Service is really solid, it scales. When I talk to your customers, they love it. But investors don't know what you do. TechCrunch doesn't know what you do." What bucket are you in? They're going to put you in a bucket, so choose the bucket yourself." And he's right.

Maybe it was the stealthy conservative nature of how we came into this — the fact that we spent no money on marketing. We never really took a strong stance in what I call the air war.

I'll contrast that with Heroku where the founders would get up at every single conference and say, "This is why you build a cloud service," and pound their hand on the table and show a curve that was going up like this. And you say, "Oh, but it's still really low on that axis, but it's going like that." And then they would say, "This is the future."

Very outspoken and not empty; logic behind it; market statements. Look at their user base that was adopting it and that type of air war, knowing what it is you do, what the market is, what you're creating, how you're changing the world. It took me until this Christmas to realize that, "Oh, we're an indirect meeting play. We build for people that do great things with our technology."

It's different than discovering the Higgs-Bosom myself with my on my own fingers, but it's probably more powerful because it's like you scatter out this technology to a bunch of companies that do incredible things. Third world supply chain management, Jnomics, finance; you can't predict what people will do with it and that's phenomenal. But I didn't have that in my back pocket yet. When I'd get a bright-eyed student right out of school that's like, "Cloudant, what do you guys really do?" I'm like, "Databases, distributed systems, da, da, da. . ."

No. We're changing the world by giving the tools to builders so they can do incredible things with them.

I think that is at the core of Heavybit and so it really resonates. Like the Heavybits and stack. You take those problems away from people and then they just take these building blocks and they couple them together to do incredible things that you never realized. As an aside, I think it's far easier to sell an application than a platform. I'm going to remember that in my next play because it's much less abstract and the meaning is direct instead of indirect.

We didn't win the air war and only recently are we really competing. Now we have a chance to do it with 100 billion dollar revenue laying behind us at the core of IBM's reinventing itself for the third time in a life or death experience. It's incredibly exciting. They're like, "Cloudant! You guys. New developers. Where are they? How do we talk to them? What's important to them?" The cost of this is too big to calculate. It's probably two to five.

It's all about speed. Adrian Cockcroft's talk is perfect. Every market is a Land-grab market whether or not you know it.

If you think you're not in a land-grab market, just hang up your shoes because it's over; because you are.

CEOs change at Microsoft, even Oracle is here. We invented the #DBaaS as not a highly focused marketing move, but now Oracle is all over it. What the hell? We're this tiny little company from Massachusetts that nobody had heard of. We're still at the top of that — second.

Finally now I get it. Andreessen's right, "Software Eats the World." Everything comes as a service because that 's a reaction to the market reality that things are just going fast. The market is efficient, winners and losers are created every day and no business line is safe, ever.

You've got to build new revenue. You've got to build new products and that means you got to reinvent the stack. The people that do it are developers and they're not the king makers, developers are the kings. You've got to sell to developers.

The enterprise right now has no freaking clue how to do this. IT, CIO, CTO, you name it. We never closed a deal with somebody in IT, ever. Cloudant's vision, if we ever really execute on our vision, IT will probably go away. You'll just have people that are like, "There's no magic stack. There's no one persistency store. I've got this problem, these are some tools. Let's try it out this weekend and throw it out there, and if it sticks then we'll add some resources to it." Then you're off and running and you've got something huge. That's the brave new world.

Here are the last few things that we got. I'll close with three. Win: Investors. Oh my god, we were lucky. If you are raising money, raise money from Avalon Ventures. They were a total unknown to me. We were in Sequoia's board room, other places through Y Combinator and then I went back to MIT and I got this email from Rich Levandov. He's like, "Oh yeah, I'm around the corner in Cambridge. I saw you at the Boston Demo Day. Come on by and see me." I went. Really sad venture office, one secretary. I was all sweaty because I was late and I waited half an hour and she said, "You know, I just paged Rich," and she's like, "he says that your appointment is tomorrow." I'm like, "Oh, shit! This totally blows." I come back the next day and he thought that was a total kick.

He came into the office for the one day and he's the only one there. I went into my pitch and after four, five minutes he goes, "Alright, how much do you want? One, two, three million?" I was like, "This dude is a crackpot. There's no way this is real." We wasted two months doing diligence on him and trying to get competing term sheets, and this and that. We didn't even let him go to a term sheet because we're like, "Nobody goes that fast." But it turns out he's totally real. He had just not invested in any Y Combinator companies. He was an unknown. He was a judge for the MIT tech competition, the 100k competition, which is a big deal.

And he invented Phoenix Technologies; he was the founding CEO and took them public. For those of you who don't know, it still boots on every single PC-compatible machine because he reverse engineered the IBM PC BIOS in a way that did not get him sued and opened up the PC-compatible market and dominated until he refused to lower the price point for a college kid called Michael Dell, and then business started to change as he lost the advantage. But anyway, Rich and his co-investor Brady from Avalon have done very well.

We were out of Avalon 8's. They were early in Zynga so that fund was locked up as a success, and everything on top of that was gravy, I think. I don't think that really defined who they are. They're incredibly patient, steadfast. They let us make mistakes. They let us walk in the wild a little bit, but they said something early on and it's like, "Look, we believe in the team. We figure you'll get in there, elbow your way around the market. You'll figure it out. We don't expect money back faster than 7 to10 years, that's about the time we'll start talking about some options." That's very rare. That's exceptionally rare. And never did we have a feeling like we were really under big pressure. All those things that we did wrong this offsets almost all of them right there.

Penultimate co-founders. Startups are very hard. I had no idea how hard this was going to be. I'd done three different types of science and kind of reinvented myself. I'm older than most people here, I think. I didn't understand how much of my identity would be wrapped up in this thing. When we started, we were just going to do this tech stuff, and we 're going to change the way people dealt with computing and put great power into the hands of the many to do data or analyze data and build applications, whatever you want to do.

It was hard. Trust and communication were so important. I've had conversations with my co-founders that are far more raw and painful than anything I've had with my wife as of yet. We've been married four years, so that offsets everything.

This is my last slide. Through all of those hard times, we could always go in and hang out in our IRC channel and talk to customers or on a support ticket or go meet them face-to-face. That was incredibly recharging. In research, if I had a really terrible day, I would go teach a class and it's like, "Oh bright-eyed bushy tailed freshman, physics. This is great." It kind of recharges you. In this game, it's customers.

These are happy customers. This is now Samsung Music. There is a company called mSpot in Palo Alto that got bought. The first contact was not the youngest one here on the slide. I think Chin, in the middle, she wandered into our chatroom one day and asked a question and we answered it. She said, "Oh, I'll try this for a weekend project." That turned into a project for our company next and then before we knew it, the CTO or VP of engineering on the right was buying machines by the hundreds. This becomes a big deal and they launch a streaming music service for Samsung on top of our little technology and our company.

So focus on the users, I think, probably offsets everything else. It just stretches it out.

So with that I think I'll pause and turn it over to Tom for questions. Thanks.

Q: Can you talk about some of the problems you faced whenever you went on-premise?

A: Sure. I should say that the story is probably not done. Overall, I think that we face an interesting challenge if you're early. I said new markets are best, but that means you're asking people to do new things. I didn't realize until actually just recently, again, we were asking people to do two new things and that's one too many. We're asking them to do their database in the cloud off-prem, we're asking them to use a NoSQL database to start which is very hard and probably affects our adoption rates. The biggest one by far is just off-premise and not doing the database themselves.

It's tricky because I absolutely believe that in a decade if you're building a new application, you will never install something yourself. Why would you do it? You'll either use a framer that directly connects to a cloud service on the backend for persistency or you'll sign up for whatever the hottest, easiest or services that maybe you want to learn about for that one. I don't think that there's going to be a winner take all. I think it's going to be this continuing evolution. I very clearly think that that's the future.

But the reality is the market of people that we're selling into now are still not there necessarily. So you've got his part coming up and in a world where you have a finite market size you've got this part trending down.

I said that we lose deals to Amazon — we lose more deals to on-prem.

People will say, "Oh, I'll just run Postgres myself." Eventually they come back. They're like, "It was successful. Now I've got to hire 20 people for a 24 by 7 ops team. I didn't really think about that." So it's there but it's not. It's like trying to sell them something they ought to do instead of something that they have to do — to borrow something from a friend, Bo Lu the founder of FutureAdvisor. It's tricky and they didn't quite get it.

I think from a sales perspective when you look at the numbers it's like where are you losing deals. "Well, they did it themselves." Well they did it themselves — we should have an on-prem offering . And we fall in prey to that logic more than one time.

Going on-prem is very hard, but we didn't do it in a very opinionated way. We just assumed, "Yeah, give us a VLAN, some servers. We'll make it work." Even going to colo providers when we had to go into South Korea, there was no Rackspace or SoftLayer there. So getting to Samsung, networking with a colo provider, six months just to get some stupid machines configured and stood up. Even then it's incredibly painful. Any little thing in your stack that you took for granted that's buried somewhere deep in your configuration management, your chef recipes, is going to bite you, every single thing. Just trying to port to SmartOS with Joyent, the simplest of shell tools was not there. Every small thing was painful.

For us the most painful by far was network and network latencies. We're a distributed system, there's a lot of RPC all over the place. We don't actually care so much about the typical latencies, we care about the distributions because when you're doing a billion operations in your database per day, it's 10,000 a second. A problem at the level of a part per million is going to ruin every single second of the day, basically. The math, you just discover things as you go to scale.

For us the network latencies and the tails on those latencies were the number one reason that we tried to get off of AWS as much as we could because of the volatility.

It's the reason that peering different data centers on Rackspace was so painful and probably why we ended up going so deeply in with SoftLayer, which if you don't know it gives you two 10 gig private fibers between all data centers. When you're throwing things up around the globe akamaize style that's huge for us. So that's the tip of the iceberg. There's a whole bunch of sociological issues, too. We built something that was meant to be poked at, collected and continually deployed to with hot patches interlying. That is not an option we have when you're running on-prem at Monsanto for instance, a tightly controlled environment.

Q: Most enterprise sites don't have a developer-only section. What made you decide to do that for Cloudant?

A: That's a great question. I wish we had Shawn here with us. He's in our San Francisco office who's our lead designer. We have stumbled on our web properties for a long time and then our first real employee, or maybe our second real employee was a brilliant designer/coder Stefan Attardi who studied CAT online. He won the first Node.js competition and then we kept him for six more months amidst these incredible poaching offers.

He built something that really differentiated us initially in 2009 era where the fonts were just right. He's a southern Italian who was educated in design in Scandinavia. Everything is just right. You know what I mean? He built a website that really did distinguish us and then it just rotted in his absence. All of his experimental code is still running actually for a large part of it. We're finally ripping it out.

We've had a marketing challenge which I think we never quite surmounted which is you need a brand identity and you need investors and analysts and reporters to be able to come in and understand what it is that you do. Then we always probably shake a little too much product differentiation attempt on that. But then there's the reality we got to teach people how to use the service if we're not going to write real documentation.

I think that two of our developers and one designer got a little fed up one weekend and said "Let's just show people how to use it in the browser." Which turned out to be great. It sat there for two years basically and we're just now reinvesting in that very heavily so that we extend all our documentation to be interactive in that sense as well as having static assets behind it.

Everybody notices that it's two distinct beasts and we'd really like to unify it into one thing.

Q: Besides open sourcing, what do you do to create a developer community around your product?

A: The only other thing that we really did was be good stewards of a few open source projects most notably Apache CouchDB. We embed parts of that persistency. We use that for persistency per node and support the API. A large fraction of our core developers are now Apache CouchDB committers. That's been our biggest funnel probably, historically.

It's been a little delicate because Apache CouchDB may be the only NoSQL database that's not vendor driven. It was a true community product, so it feels a little weird to come in there with venture money and try to dominate it. In fact, the venture money that poured into the original founder Damien Katz really confused the space and then he left. They acquahired to NorthScale, Membase and now Couchbase, which is not anything to do with CouchDB. The community kind of spiraled a little bit and we just tried to be good stewards and build it back up. Now it's had an incredible year.

In my mind it's like the Postgres MySQL story. Apache CouchDB is the Postgres of the NoSQL market. It's slow, it's deliberate. It's not really vendor driven, but it will five, ten years down the road be the thing that the next Heroku runs on the backend for persistency, for technology reasons. But it's completely unmarketed.

That's the number one thing, getting involved in open source communities, I can't stress that enough. That's where you find customers, that's where you find people that you're going to hire.

One interesting stat, I tried to dig it out of Salesforce before I got here, but I couldn't quite find it. On e of the last board meetings that we had for the acquisition was December and we made an interesting measurement. A lot of the deals we had closed in the second half of 2013 were folks that had actually been in Salesforce for 18 months. They had come in, they had kicked the tires and we're just starting to see them come back for the next project or the next something. That was pretty fascinating. They maybe come in initially through CouchDB, but then we kind of gotten them into the brand.

I f you're going to do one thing, do open source projects, that's it. And I think the folks at Meteor.js are doing a great job with that. Neo4j has been phenomenal. Riak has done great. True open source communities.

Q: How do you determine pricing?

A: So the question is pricing. Boy, that's hard. Pricing our multi-tenant service is something that we probably never got right. In the end, we've just largely gone to free up to five gigabytes of data and some million of operations. I'm going to separate that from my dedicated pricing because dedicated pricing we absolutely got right. Nailed it first time, it was easy. Probably under priced it, and I'll tell you about that later. But the multi-tenant one is probably more relevant for folks in this crowd. You have a service people are using and it's very abstracted. That was tough because you can think about it, "Okay, ten cents a gigabyte for object storage, but it's a database so is it 10x more because you're indexing everything." It was kind of tricky and at the same time Amazon was driving prices down.

We decided to measure what our costs were and go forward with a small something that could be viable financially just from a hardware perspective alone, not counting people or anything else.

We were like, "Okay, what matters to us is IOPS. We knew how much IOPS cost on every one of our providers, so we'll count IOPS and pass that back to the customer." That's exactly what DynamoDB does. There's an API. That API somehow maps onto IOPS and it may be shocking in some cases based on the API call that you make, like table scan petabyte. That's very expensive from an IOP perspective. Our users didn't get that at all. It was very surprising and it just didn't correlate enough with the actual API calls that they were making for them to understand.

We went back to just basic meter pricing which was on storage and number of requests and we went light and heavy. Even now they're like, "Well, I make this one API call to set these two clusters up in a master-master configuration, that's costing me a 100 bucks a month. I don't understand why." Yeah, that's a non-trivial API call. You're setting up two replication pipes in both directions. That still tends to surprise people, but we realize that our multi-tenant service is really just a fantastic way for people to learn about the service. I guess that speaks to your question. Standing up the multi-tenant service and trying to do that well was very important for us also.

The dedicated, and when we say dedicated that means that okay, you've launched an app, you're happy with it in this service, but it's metered and you're not quite sure how much it's going to cost and you're also sharing with other tenants in the system. As perfect as you try to be with resource boundaries, it's still multi-tenant. You can transition in Cloudant into a dedicated cluster. It's a minimum of three nodes and it goes up from there and you talk in tronches of a dozen servers and then the price goes down. The big switch is you go from metered to tiered, so it's all in, no bandwidth, no nothing. No overages, nothing. You know exactly how much you're going to spend and it's per server.

Per server is something that we want to get away from in the cloud, we want to be abstract, but people still know how much a server costs from Rackspace. They can look at it and be like, "That's a good deal." Because when you're buying thousands of them then you're getting them for significantly less than the typical four-person start up. So that one we're able to price and stick to.

That said, a decent chunk of our users come to us after spending a lot of money on Amazon RDS, which is maybe three to four thousand I think for the median Y Combinator exiting company just coming out of YC. Surprising what that spend can be. We have five or six of these now where they come to us and they do this at scale and are like, "Wow, you guys are saving me x large numbers per year." We had one enterprise customer that came to a party we had and he was like, "Yeah, you saved me one to two million dollars last year." It's like, "Oh, we totally under priced that thing." Those are big numbers.

At that level you just want to get people into the service because the fundamental math of how we go up into the right is if we just add customers linearly in time, and each of those customers grows linearly in time then we get T square growth. That's a very good business.

Then if you can accelerate the rate at which you add them and have a few that really hit then you get toward exponential growth. That's really the promise of the cloud service.

A: When did you decide to start spending money on marketing?

Q: See me over beers for a complicated discussion on marketing. I would say it's something that we've done much better at. We started spending money on marketing when we had spent our first two million in venture money and we'd gone three years on that. Then we we're going to raise a Series B, but that was a little tricky so we did a bridge with our existing investors and maybe they gave us two million more. We brought Derrick on board and then he brought a marketer with him who is still our VP of our marketing, Andy Ellicott.

Andy came from a very different world of traditional on-prem database companies. He had launched a few Mike Stonebraker companies, Vertica, VoltDB, a lot of stuff around OLTP. Very good at actually marketing to the traditional style analyst, CTOs, CIOs. It's really funny, most of you probably hadn't heard of Cloudant before tonight or maybe before the acquisition, but every single analyst had which was really interesting to me. We marketed in kind of that traditional way and we spent a tiny amount on that. Only now Andy is really bullish in leading the charge for like, "Whoa, we're going to spin this around and market it to developers, run events." And here's why, I forgot to say this; I wanted to.

Any of you guys use Neo4j in your stack? Know it? It's the clear winner in graph databases. They own the graph database market. It's a small, lean company, probably under 80 people. They're headquartered just down the peninsula. Guess how many events were run last year for Neo4j? Any guess? It's like 370. Yeah. That is the power of infectious ubiquity community marketing play. They are not exceptionally heavily funded either, but they just have that laser focus on saying, "Hey, data is relational, but not the way you've been thinking about it. Everything is a graph in the world." They go into communities and they get developers so excited about that then it starts to spin and it takes off on its own.

That's I think a great example of the new style of marketing. You've got to find the two ways to blend those. I don't have the right answer. I don't think anybody at Cloudant, including our marketing department, would say that we really knocked that one out of the park because it's something we struggle with.

It takes a very new style I think to market to developers. No developer wants to be marketed to in any sense. That's a trick.

We started spending money when we hired a new CEO and he's like, "Okay, we're going to spend some money in marketing. We're going to test some things out." It was kind of experimenting to a large extent, but we started to have good success.

Thank you.