CI/CD is Your Product

Problem

A friend of mine asked me to help a startup founder named Jimmy (not using his name to protect the innocent) who needed to deploy his software product because he just landed his first enterprise customer trial. I agreed to help because founders are pretty fun to work with. On his machine, he could demo the product super well on his local machine (the old localhost.com joke). The hard part however, was when it came time to deploying the product. Pretty much most founders run into a problem here if they are not using an automated setup, but even then, Been almost always required always requires deeper knowledge that modern agentic systems cannot fully automate without humans. It is close, but also not close.

We rush to get a solution out to he could do automatic deployments because we like to be fast. Speed is advantage. In this case however, speed led to many back and forth conversations and experience dripping with subtle frustration. For a services company, our job is to eliminate frustration, friction, and pain as much as possible. This image depicts this exchange well.

I always think about the Navy SEAL saying I remember hearing at the Naval Academy.

Slow is smooth, and smooth is fast

What We Learned

Fix Vibe Code Stuff Immediately

It's better to use bare bones is a lot of times vibe coding takes shortcuts. Vibe coating is great shortcuts that we see is that solutions are created without a database, ORM, or API. These apps and instead was using files saving data saving files in a modern web application. We have seen this before where it's much easier to build a solution out without writing to a database because it saves you a lot of steps in frustration from somebody who's prototyping a project. Problem is, is it kicks the can down the road and ultimately leaves and makes a bigger hurdle to get over.

Start With An Infrastructure Blueprint

could build a test instance, a staging instance, etc. but at a minimum should have an infrastructure blueprint that says basically what are you going to build this solution on whether it's a-- front end, back end, or a monitor or a monolithic solution. You should have a well defined stack that your team uses on a consistent basis. For example, if it's AWS, you want to make sure that you have an agent lined up correctly that uses Terraform. It's better to use bare bones bare-bones systems now that are full that are fully flexible than it is to roll out these automated tools because there are limitations on their platform. Barebones AWS is far superior.

Environmental Variables = Crown Jewels

Problem is, is it kicks the can down the road than setting up your environmental variables in all your key locations. typically environmental variables just kind of get mashed in there with an LLM you talk about it and say, Hey, do the deployment and then you rely on the LLM to do things like protect your keys in annoying ways by saying it can't show you the key, it can't look at passwords, et cetera. But I think this is perhaps one of the issues that gets glossed over and that's not having exact knowledge of your environment your environmental variables. Where there's-- where they're stored, how they're defined, etc.

Build Clear Merge Notifications

You're also missing into build instructions that report out successful builds who built it, when they built it, or conversely if a merge was done in production and there was a problem. Who caused the problem and clearly what the issue is.

But the message should be very clear and configurable. It should be very clear and provide next steps for a founder who's working at two in the morning.

You need to understand everyone what it's used for, how is it protected, how is it safe along every step of the way, anywhere where you need environmental variability environmental variables, it should be protected in production off of developer boxes and typically in a secure container like AWS Secrets.

Build out a real environment with a dev instance and then a production instance that is off of the developer's machines. could build a test instance, a staging instance, etc. but at a minimum you should have a dev machine that is out there where everything builds and compiles and runs off of your machine and everything can you can run full scale tab full-scale tests there and only have one production instance where everything is secure.

When the founder won the title, When the founder wanted to deploy it, it opens up a whole gateway of conversation conversations that most founders are not ready to have. And one scenario led to lots of painful late night, tech night, text messages and frustration with the founder who was trying to push software in a CICD pipeline that was not mature. It definitely led to a strained relationship and potentially a failed demo. On Monday with a real paying client.