DEV Community

Cover image for Get your end-to-end pipeline ready before coding any features
Sten for Tability

Posted on • Originally published at blog.squadlytics.com

Get your end-to-end pipeline ready before coding any features

When you get a great idea (and after it's been validated), the next thing is to start building your MVP. But instead of implementing any of the required features, it's best to begin by shipping a "Hello World" to production.

Late deployment pipelines are costly

A lot of teams have adopted Continuous Integration because it allows them to move faster. By integrating the work of everyone early and often into the mainline, you reduce the risk of conflicts and you make it trivial to understand what is breaking.

The same thinking needs to be applied to deployments. Every week you're going to be solving small configuration problems. Missing dependencies, env variables, service configuration, monitoring tools... As you add more features to your software, you will also increase the amount of configuration required for it to work. If you wait until you're satisfied with your local tests to release your app then you're likely to spend a significant amount of time figuring out how to set things up in a public environment.

The better approach is to start with your classic "Hello World" and to ship that in what will be your production. It doesn't matter if it's on mobile, desktop, web. Just make sure that you know how to deploy what you're building. And then deploy your work early and often, every day if you can.

You will drastically reduce the risk of releasing and, while it looks like slowing down at the beginning, it will make you move faster. Some platforms have hard constraints on what you can ship, and you want to figure that out right from the start instead of having to refactor your code down the line.

Ship early, get more feedback

Now here comes the real benefit. We tend to vastly overestimate how finished our work has to be before we can show it to others. So we keep adding features after features. And then at some point, we judge it ready and put it somewhere where others can play with it.

Having your application being accessible early will help a lot to fight that tendency. Of course, it's best to keep things private until you can safely onboard people, and there are many ways to do it:

  • Private URLs
  • Password protection
  • Unlist your app on marketplaces

But the point is that you want to be able to pull out your phone or your laptop at any moment and show what you're working on. The more feedback we get, the better we can make our products. And this is also a great way to get early adopters.

Top comments (0)