These days we revel in the fact that we can push a button and stuff comes to us. Cars::Lyft, Meals::DoorDash, Groceries::Instacart, Movers::Lugg, etc. We reliably get X and company Y does all the heavy lifting for us. Of course we pay a premium for this, but the saved costs in time and/or stress of managing and maintaining the process ourselves make it worth it.
This full-stack “X-as-a-service” idea is nothing new. When a firm is able to specialize in delivering a very specific service and grow to a certain size, it can achieve economies of scale and pass on its efficiencies in the form of lower costs, better performance, and higher reliability than customers could achieve themselves. The most game-changing companies in this vein of the past decade have been cloud providers: companies, like Amazon and Google, that can provide all your infrastructure needs with the push of a button.
Not long ago, to launch a site, you had to buy or rent your servers and then manage them yourself. It was costly and a huge headache. Now, with cloud providers, it costs just a few bucks to get up and running, and you needn’t accumulate any assets. While it isn’t a one-to-one replacement for a data center, running on a cloud provider should be every entrepreneur’s go-to choice when starting an online business or creating an online presence. The main reasons to do this align well with the four basic rules of running a startup: 1) launch a minimum viable product as soon as possible, 2) focus on your core competency, 3) iterate quickly and fail fast, and 4) keep burn low.
Rule 1: Launch an MVP ASAP
You should put a product in your user’s hands as quickly as possible. This seems obvious, but many companies still fail to do this. Instead of launching, they spend months (sometimes years), trying to perfect their first version. In most cases, they overbuild in an incorrect direction, and by launch have run out of money and time to fix it. This can be avoided by getting feedback from real users earlier.
This doesn’t mean you should rush the initial build or that you don’t have to be thoughtful. Instead, separate out your initial product requirements into two buckets: must-haves and nice-to-haves. Everything in the first bucket is a must-need to solve the problem, i.e., if you don’t build it, the product is useless. Throw out the second bucket. Real user feedback will guide your roadmap.
Once you’ve built your first version, launch. Cloud providers are the mechanism to swiftly get you to market. Just put in your credit card, spin up a machine, push your code over and voila, your application is up and running. Why spend days messing around with your own infrastructure, when you can get what you need out the door as soon as it’s ready? Don’t let unnecessarily wasted time stand between you and your users.
Rule 2: Focus on your core competency
Trying to build your own infrastructure may highlight your technical know-how but it also highlights your lack of focus. Not the perfect combo. Often investors ask, *”What is your go-to-market strategy? What do you need to launch and how will you get users?”* Building everything is not a strategy. In fact, it shows a lack of strategy.
Misconception: “But big companies do it!” Big companies have economies of scale. They can do multiple things at once and have the staff to be experts at many things. If you look back in history, big companies got to where they are by focusing on just one thing initially. Even Amazon itself started as “just” an online bookstore; AWS was a product that came years later, after dealing with all of the traffic and infrastructure Amazon had built.
At the end of the day, it’s about making something that people really want. What is it that the customer is paying you for? Focus on adding that differentiated value and getting really good at that rather than spending time doing all the heavy lifting of racking and stacking servers. No one else cares about how cool or fancy your infrastructure is. That’s all hidden. Your startup will fail or succeed without people caring about your infrastructure, much less knowing what it is.
In the early days of your startup, you have limited time, resources and money. You’re fighting to stay alive and any time spent away from the actual product, not making money, and not getting users is time spent away from making the business successful.
Rule 3: Iterate quickly, fail fast
Startups are volatile. Good and bad things happen every day; the volatility is just something you should expect. One day, a publication randomly writes about you and suddenly you have more users than you imagined you could handle. And then the next day, you cross land in the the trough of sorrow, and you don’t get any traffic for a while. And then, maybe n weeks later, you pump out a viral feature and stuff suddenly grows endlessly.
The key to getting through it all is iterating quickly. Experiment with new features, get feedback from users, and, through trial and error, you’ll get better direction on what to build next. Don’t be afraid to jump around as well—in the early days, you want to shoot for global, not local, optimizations to your product. You know you’ve hit on something when you start to see growth.
Misconception: “Well, it can’t be that hard, it won’t take that much time…” Oh boy, don’t tell that to any sysadmins! Yes, v1 may be easy to deal with—after all, you have zero users. But what you won’t be able to predict are all the edge cases that will appear and the endless customer service support you’ll need to provide. Worse, if your startup suddenly grows, it’ll become dependent on how quickly your ops team can get things done. Maybe it “just” takes one engineer away from everything, but that’s one engineer too many. You could’ve paid a fraction of that to a cloud provider that covers many (if not all) of the scalability use cases you need. (Also, it’s probably really hard to beat the 99.99% uptime of the most popular cloud providers.)
Cloud providers allow you to do all this seamlessly due to their elasticity: they give you the ability to scale up and down as needed. Personally, I think this is what makes cloud computing so beautiful. Before cloud providers, you would have fixed capacity for a set period of time and could only get more resources if you physically got new servers. These days, cloud providers can automatically add capacity into your infrastructure as needed. The cloud allows you to iterate quickly and grow rapidly.
Just like you may need to add capacity, you might need to deprovision servers as well. Before cloud, you’d be stuck paying for the servers you bought or rented, but with cloud providers your idea can fail and you won’t be stuck with expensive infrastructure. In effect, cloud providers allow you to fail fast. If your idea doesn’t work, you can move on to the next idea without having to deal with underutilized expensive infrastructure. Being able to do that in a very quick and fluid manner makes experimentation fast and low risk.
Rule 4: Keep burn low
Many startups fail because they run out of money. When you start off, it’s important to keep your burn low—thus extending your runway and giving you more time to figure things out. The advantage of using a cloud provider in this sense is obvious: there are no capital costs. To launch, you don’t need to pay the initial fixed fees for a fleet of machines and the ongoing costs to house, power, cool and maintain those machines. And, best of all, you only pay for what you use. If there’s no traffic, you don’t pay for idleness.
Given the popularity and intense competition amongst cloud providers, many offer a free tier to get started. Some providers—including AliCloud, AWS, DigitalOcean, Google Cloud, and Microsoft Azure—give startups as much as $120,000 in free credits. Sure, it’s an attempt to lure you to their platform for the long-term, but you’re a startup and money is tight—take advantage of whatever you can get!
Misconception: “But what if I get big like Snapchat? So expensive…” Snapchat is still on Google App Engine, although I’m sure they have debated internally whether to remain due to costs. These are all good problems to have. For sure, at a certain scale, you’ll need to hire a team dedicated to devops. You should think about the future and choose the right cloud provider for you before you start, but don’t get obsessed with what you don’t know today. Maybe one day you’ll need to transition to another service, move to multi-cloud, or even build your own datacenter solution. At that point, you’re probably nearing unicorn status and can afford it. Get past Step #1 first: build a product that actual users are using.
I must admit that, despite all the benefits of cloud providers, there’s something romantic about building everything from scratch—you’re in control of your own destiny. But while the extras you get out of it over a cloud provider may earn you some karma points, it’s never worth the time you will lose by not remaining focused on your startup. Remember: your goal is to build a successful company. Don’t re-invent the wheel.
This principle extends not just to cloud providers but to a slew of API-driven SaaS offerings that are now available. For example, instead of fussing around with payment processing, you can implement Stripe in minutes. Instead of archaic background check systems, you can use Checkr. For SMS messaging, you can use Twilio. Even biotech startups don’t need lab infrastructure these days to get started, and can run experiments in the cloud via Transcriptic or Emerald Therapeutics. The list goes on…
That said, there are so many tools and APIs available (even within the cloud provider’s offerings itself) that sometimes it can feel like you’re a kid in a candy shop. I want to use all of them. All of it. All mine. Don’t. The sugar hangover of over-implementation is going to be a nasty and potentially expensive one. Remember, focus on the process of building your MVP. Choose a cloud provider and the set of tools you really need, and go.
The takeaway is this: focus, focus, focus—and focus specifically on the single thing you’re going to be better at than everyone else. That is your competitive edge. Build a great product, listen to users, and repeat. Outsource everything else—especially your infrastructure.