It's been a long time since maintaining your own servers was the best way to deploy a service. GCP and AWS are clear winners in the space. But like all good things, don't go overboard. There are many services you should steer clear of. You want to prevent vendor lock in so you can migrate to a competitor if need be. More importantly, there's often higher quality cheaper solutions if you can roll it on your own. This article gives a few examples of the tradeoffs.

MVPs are constantly changing to adapt to the market and needs of users. You have to be very judicious in your testing, so that you don't waste valuable cycles on things that will be thrown out soon after writing, or something that just lengthens development time beyond what the market can bear. You don't want to be crushed by a competitor because you were writing duplicate unit tests for your backend that will be rewritten in a month. That said, I'm going to go through the major types of testing, and when they'll be useful in your product lifecycle.

When hiring your first engineers, it's important to show them you have a plan for their success at your company. The best way to do this is to have a promotion pathway laid out for different levels of engineers at your company. Aligning individual contributor goals to broader organization goals ensures mission alignment and work is focused.

Doing a competitive analysis on your MVP and business idea yields many benefits. It helps identify gaps in the market, shows where the attention and money is focused, and may expose features that are extremely technically complex. It's a good thing to do before starting building your MVP to ensure you're hyperfocused on your unique value proposition.

With a functional app, you want to test before putting out to early adopters. Early adopters are going to be your biggest fans, so you want to get the experience as close to right as you can before launch. This is where usability testing comes in. Running a series of interviews with potential customers who haven't seen the app before is best.

When building an MVP, you want to steal as much code as possible. You're not worried about code licensing, you want to validate the market as quickly as possible with open source. So you want to use third party libraries to do the heavy lifting in your app. This is the heart of most great new companies, leveraging an emerging technology to serve a new market. Uber didn't build a GPS mapping system in its first version. Google didn't build an NLP system in its first version. Netflix didn't build a facial recognition library for identifying actors in its prototype. You shouldn't either. This article gives a few tips in identifying and using existing libraries for your MVP.

Interviewing engineers is a complex task that requires special skills. A new industry has popped up catering to this need — Karat runs interviews for medium to large sized companies, with some customization. Because the engineers and the core of your company, you should be thoughtful in who you hire and why. As the graphic above describes, the cost of hiring a bad employee is huge, whereas the cost of not hiring a good employee is not that high. Always err on the side of caution when making full time hires. Here, I'm going to give some thoughts on how best to conduct your process.

There are a few virtualization choices out there, and for most startups this choice is necessary. Buying a server is all but completely impractical in this day and age. So it comes down to a few top companies. I have a clear bias toward GCP, and I hope to make the case for it here, but there are reasons to go with other choices in certain circumstances.

No Code solutions have come a long way in the past few years. But there is still a lot to consider before committing to one of these solutions.

No Code solutions have come a long way in the past few years. But there is still a lot to consider before committing to one of these solutions.