Ship products on day 0.

Picture this. You have a new idea for a SaaS application; you spend 4 months getting through product validation and development of an initial alpha or beta version. Finally, the team attempts to deploy the initial version to prod. Everything breaks. The whole time, the team was developing stuff locally or in lower static environments, and now there are a bunch of extra hurdles to jump through to get it working in prod. Silly, right?

This is one of many great reasons to ship products to prod on day 0. As soon as engineering starts, deployments to prod should be happening, even if public endpoints aren’t being exposed. This does a couple of things for your product delivery journey:

1. In order to “deploy to prod,” you have to engage all of the players from various work centers/specialties up front; design, frontend, backend, architecture, security, networking folks, etc. This way, you get everyone’s opinions about non-functional and functional requirements and implement them right away, instead of batching them all up for the big-bang deploy.
2. You’re conducting testing and analysis of the code being checked into the repository from the beginning. This makes it easier to catch errors, bad practices, and security vulnerabilities as software is being written, as opposed to at the end.
3. The developer experience is self-service from the beginning, rather than requiring dependencies between work centers/teams early on. Using this model, software engineers will typically be able to be more productive and have more control over the environments they manage and deploy to.

By the way, I write one of these every few weeks or so. Sign-up with your email here to receive the latest, as soon as it’s posted!

Email Address:

Basically, we’re removing common constraints that are not related to development or product design. Check this out:

[Once all technical] constraints have been broken, our constraint will likely be Development or the product owners. … When the constraint is here, we are limited only by the number of good business hypotheses we create and our ability to develop the code necessary to test these hypotheses with real customers. ¹

This is an excerpt from “The DevOps Handbook” and it illustrates beautifully what we can accomplish if we avoid creating these useless constraints from the beginning. Now we are only limited to the amount and interval of business hypothesis we can generate, to then test and realize through our software development efforts. To practically implement this model of product development, you need only do a few things:

1. Automate manual tasks away using CI/CD Pipelines, dynamic environments, and developer-driven workflows.
2. Only require approvals from the people closest to the work, while making sure you include people with different focus areas/perspectives.
3. Avoid large batches of synchronous work. i.e. sending a large batch of new stuff for approval or testing to a specific team or work center.

If you need help with DevOps and software delivery, reach out.