Yonas Beshawred
StatusPage.io has been pretty popular as of late. But getting to this point was far from easy. They've touched on how they got to . But over at Leanstack, we immediately wondered how they built their initial product and what their build process looked like. So we sat down with , Co-Founder at StatusPage.io to get the details on exactly how they built their v1.
"Empathy is the single most scarce resource that we have as human beings...When we came up with the MVP, we had to stop thinking “what’s the cool tech we can build” or “what’s gonna be fun to work on” from a developer’s perspective."
"We design for the novice, configure for the pro. But where you put that line in the sand for designing for the novice is up for debate. And a lot of times, you have to talk to a lot of people to figure out where that line is."
LS: So would you tell everyone a bit about StatusPage? How did the idea first come about?
S: We had been product managers and developers before, and done contracting work. And we were struggling to communicate to people that, you know part of builing an app is building out stuff that integrates with other services that you don't want to have to do yourself. Things like email deliverability, SMS deliverability, we don't host our own servers. We don't do a lot of things these days. We just focus on the core offering of whatever our product is. And so we had, in the process of interacting with other services, come across a number of status pages that we thought were quite terrible. And a couple that we were really inspired by. Namely GitHub and Heroku. And they were the ones that had taken the first step and put a stick in the ground to say that if you're hosting a service, anything short of full transparency is not in your favor. And that if people are going to be paying you money every month for something you better damn well tell them how well you're using their money and how well you can communicate when things are down so that they can do their best at least to route around it or to communicate with their customers, like "hey, we're not sending emails out right now. We understand our provider's having trouble and here's what they've told us." And so based on that, and the skills that me and Steve had had, we just set out to build what eventually turned into StatusPage. Which is hosted status pages, for any sort of API, or web service that people are most likely paying money for on a monthly basis.
LS: So let's get into how you guys approached your MVP and coming up with requirements for it.
S: The speech I sort of give about building products and about being an entrepreneur is that empathy is the single most scarce resource that we have as human beings. And anything you can do to increase that or become more in touch with that is definitely something you should do. So when we came up with the MVP, we had to stop thinking "what's the cool tech we can build" or "what's gonna be fun to work on" from a developer's perspective. We had to get back into customer mode and say, "If I could design GitHub's or Heroku's ideal status page, what would that look like? What would I want to see, as someone who's paying them money?" And it shifts your mind into a different way of thinking about the problem in such a way that you can become a consumer again and you start to empathize with who you're eventually going to be selling your product to. So in short, the four requirements we came up with, were a reflection of that.
LS: Right, so this was basically the bare minimum of what you would have actually wanted in a service that provided this.
S: Right. And just to clarify, when we say MVP, we mean what is the minimum set of functionality with which you can go forth and test your assumption. People usually think of MVP as, "What do I just build to launch a product." We put a stake in the ground and said this is the type of service that we want to exist. And maybe we're the only ones. But we need to go figure out, if that's the case. So we sort of sat in a room and said, "what do we want as consumers of status pages." And then we'll go get all the vendors to sign up for our service. Because then ultimately we're consuming exactly what we wanted them to build in the first place.
LS: So at this point, you knew what you wanted to build. Let's get into the How. What was the first thing that came to mind when you started to think about what technology you wanted to use?
S: One of the core tenets that we had in terms of us being customers of this as well was that if we were going to be purchasing a solution that provided a status page, we would want the story around the technology that was running that status page to be really solid. And back to empathy, we were thinking to ourselves "ok, when are people going to interact with a status page?" They're going to interact with a status page when their site's down, their customers aren't happy, and we're kind of the last hope that they have to be the authoritative place of information that they communicate to users. In the worst hour, how are people going to interact with StatusPage? And so, around that, we made this decision early on that this was going to be part of the big story. Not only do we have to get greenfield customers that don't have a status solution already to use us, but people had already built their own status pages and were using open-source versions. And part of the core thesis was: can we get people off of that? And how are we going to do that? And part of that in our heads, was that we have to build this story around the technology, what's backing StatusPage. "You need to use us instead of this open-source solution because of X." Technology was a big part of that.
We had known Rails from a while back so it was an obvious choice. And getting started on EC2 was maybe the next best thing besides Heroku. Ultimately, going with Rails was a good choice. If we switch to Node in the future, then so be it. Whatever is going to serve the business and be fun to hack on. We may eventually throw away Postgres for something like Riak. So that it's eventually consistent but it's distributed over a couple data centers. There's a lot of things like that, in terms of MVP, that we knew as long as we continue to use the stack that we were used too, which was Rails, Postgres, Linux, to test the fundamental assumption, then it was fine. Because it was super quick. We're still outsourcing a bunch of stuff, Twilio is doing our SMS delivery, Mailgun's doing our email delivery. So you could say that we're sort of dogfooding our own thesis, that eventually, in terms of building this story around the technology that's behind StatusPage, we may have to do our own deliverability, we may have to load balance between two SMS providers, but for now, that was the stick we put in the ground to say, this is going to validate our assumption.
We had a couple of other things. We had Papertrail for logging. Librato for metrics. Stripe for payment processing. Google Analytics of course. We're actually using Segment.io to send events to a bunch of different services in terms of analytics. Mixpanel, Trak.io, GitHub of course. So there's a handful.
We weren't basing a ton of decisions off of these analytics services originally. We just wanted to start backlogging a lot of the data that we were eventually going to be interested in. We're also pretty hesitant to introduce new analytics solutions just because if you measure it, you're obviously going to be interested in optimizing it. So we have a sort of self-constraining behavior there where we make it a point to only measure things that can really move the needle in terms of the business. And our attitude about analytics early on was "are things generally working. And if they are then fine." We don't need to worry about optimizing for now. Eventually we'll use Optimizely in a real way as we start to eek out conversion rates and things like that that are better for us.
LS: Was there anything besides Rails itself that was important for you early on in terms of frameworks and tools on top of Ruby?
S: sidekiq was a big win for us. It's just a threaded background worker for Ruby. With StatusPage we have this weird traffic profile. We're either serving not a lot of traffic and we're not sending a lot of emails or notifications or we're serving a boatload of traffic and sending emails out of our ears. And so we needed something that was going to be able to respond quickly, something that could have a ton of bandwidth, and it turns out a threaded model of background workers versus a process model can work out well to start out with.
LS: Would you talk a bit about your build process? So you got to the point where you knew what you wanted to build, what you were going to use, and so the next step was to code. What did your build process look like?
S: At first it was just me and Steve for the first five months. And we had about as perfect of a split as you can get. So I dealt with all the servers, ops, backend development, and Steve dealt with all the font-end development. Javascript, CSS, etc. We have a very good working model where either of us can get out ahead of the other and it works out fine. Either I just take a machete to the UI and he eventually pretties it up, but it's functionally working in the database. Or he will sort of stub things out and I'll go back through to hook things up to make sure they're actually working. So we had this checklist of stuff to do. We had sort of agreed upon an MVP, involving customers along the way in terms of mockups like "what do you think of this feature vs that." We would show them working prototypes and have them give us feedback. So even before we were launched and accepting dollars, we had people that we would get on GoToMeeting and do screenshare with and say "Is this working out for you, does this make sense?"
And there's product tradeoffs that you can make. One of the adages we have is, design for the novice, configure for the pro. But where you put that line in the sand for designing for the novice is up for debate. And a lot of times, you have to talk to a lot of people to figure out where that line is. So we could mockup things on a whiteboard and say, "if you had these six things, does this make any sense at all?" So there was a lot of things that we could do along the way without actually having a functional website and taking money to help us guide these product decisions.
LS: So it sounds like you had a good separation of duties and you were involving folks along the way. And then of course, you had some testing. What did your testing and deployment look like?
S: We don't really have functional tests, it's all unit tests and integration tests. And so we test at the model level and otherwise we're spinning up a headless browser and exercising the login form, going and clicking on stuff, waiting for an AJAX response. We have pretty good test coverage. Enough to where we're using CircleCI, and once that's green, we're pretty confident we're not gonna mess up the build. We're not gonna mess up the deploy. And we were using CircleCI even early on. So once the build's green, we push the fresh code. Steve, Danny, and I, we all have access to push code. Once everything is green, and assets are compiled, everything gets synced to S3, the new code goes up, we kick the Unicorns, they do a hot reload, where a new master process comes up transparently in the background and the sidekiq workers get a hard restart.
LS: So that brings us to the launch. How did that go?
S: We were live for about six weeks and accepting payments from real customers before we had even launched on HackerNews and said "we're live, look what we built." And I think that's one of the big disconnects with people that build products. You think that you just code in your basement and then you flip the switch and TechCrunch writes an article about you. And that's usually not at all how it goes. Like Square launched their pay with cash via email feature recently, and I'm sure that for months that was live in production. So we had been beta testing with live status pages, full subscriber model and everything, we just hadn't turned on the marketing gas yet.
So when it launched I think the response was good. We launched in March, by the time we entered YC in June, we had 20 paying customers at 50 bucks a month each. But looking at our growth through Y Combinator, we doubled our company three months in a row, doing a thousand in revenue, then $2500, then $10,000. All of that money didn't come in just randomly in those three months. It was definitely this building effect. It's tough but if you know how to interact with the HN community like we do, you launch this product, they go "oh ok, I'll file that away for later. We've been kind of looking at something like that, maybe I'll bring it up to my boss next week at our weekly staff meeting." But it's often times very discouraging when you get a bunch of signups, people sort of don't know what you're doing, they're just like "why would I buy this instead of using an open-source thing?" Staying heads-down and continuing to work on product is often times very difficult, but it's the only way you can kind of build on that momentum. Being out there, being present in the community, talking about us building our company, being transparent about our numbers, people are rooting for us and they understand the value that we provide.
LS: You guys definitely do a good job of interacting with the community and staying active. Going back to your tech, it seems like your stack hasn't really changed since you launched. That's pretty amazing. You had to sort of build in a strong architecture and tool set early on because you wouldn't have the luxury of switching everything out. You had to build that trust.
S: Right. So it's easy to build an MVP when you've been using Rails and doing web dev for the last six years. You understand what's going on. You get to build an edge Rails application, everything's brand new, everything works all the time. You're super-efficient. You go from thought to code and test in a matter of minutes instead of hours trying to figure out some gem issue. So not being marred in technical debt definitely played to our advantage.
In the process of thinking about StatusPage, there's a lot of the softer things we had to think of while we were building. Things like where's our DNS hosted? How does that conflict with our customer's DNS hosting? Where do we draw the line in the sand for what we want to have control over and what we outsource? Like log processing, it's easier for us to outsource than say our Redis database for example. Having said that, all of this comes with a tradeoff. I have to carry my backpack everywhere because I'm the ops guy, so I can't be out of cell service either because if servers go down I have to deal with it. To this day, things haven't really changed because we covered the basics in terms of what people need in terms of the technology story. We're hosted in Oregon, we have failover to Ireland, we control the switch in terms of when that failover happens. So once we've satisfied the basic story around the technology to people that are paying us money, we can start to evolve the stack.
When I was on the plane yesterday, I was reading something about Riak. Like eventually we're going to be using Riak in a more real way because it let's us run in different data centers across providers even, so we're not using multi-AZ stuck within EC2. We can actually run Riak in EC2, Rackspace, SoftLayer, Linode, and then we have this distributed system that doesn't require me to carry my backpack everywhere because losing a node doesn't mean much to us, so it's definitely going to evolve in the future. But I think that we're continuing to, in terms of MVP-land, come up with theses around, instead of just will people pay for this, now the thesis is how do we get people to pay more money for this, how do we drive more value. We're getting a lot of inbound requests from universities, from people wanting to use StatusPage internally, well that comes with a different set of requirements, so we have what they're telling us they need. But that might just be them right. So we're consistently coming up with things to build and test and our stack will continually evolve with our needs.
LS: Awesome. We're looking forward to keeping up with you guys and seeing how your stack evolves along with your business. Thanks for your time Scott.