There’s a moment in every custom software project that nobody puts in the proposal. It arrives about six weeks after launch. The application works. The crew is using it. Then somebody asks for a small change: move a field, add a status, fix the thing the dispatcher keeps mentioning.
How that change gets made tells you almost everything about how the application was built.
In one version of this story, a developer edits some files, copies them to a server, refreshes the page, and says “should be good now.” In the other version, the change goes through a pipeline. It gets reviewed, tested automatically, and deployed the same way every previous change was deployed. And here is the part that matters: it can be undone in minutes if it breaks something.
The first version is how most small-business software actually gets maintained. The second is called CI/CD, and it’s the least glamorous thing we sell.
What CI/CD means in plain language
CI/CD stands for continuous integration and continuous deployment. Strip the jargon and it’s three habits, automated so they can’t be skipped.
Every change is checked before it lands. When code changes, a machine runs the tests, checks the types, and scans for known problems. Every time, on every change, including the boring ones. Humans are good at reviewing logic. Machines are good at never getting tired. The pipeline does the tired part.
Every deployment happens the same way. No “copy the files and hope,” no steps that live only in one person’s head. The release process is written down as code, which means Tuesday’s deploy and December’s deploy are the same deploy. Repeatable beats heroic.
Every change can be reversed. If a release causes a problem, you roll back to the previous version in minutes, not over a lost weekend. The rollback path isn’t an emergency improvisation. It’s part of the release plan from day one.
That’s the whole concept. It isn’t exotic. It’s the software equivalent of lock-out tag-out: a procedure that exists because the failure it prevents is expensive, while the discipline itself costs almost nothing once it’s set up.
Why release discipline is an honesty issue, not a technical one
Here’s the claim in the headline, made plainly: CI/CD is what keeps a development relationship honest after the invoice clears.
Without it, every change after launch is a small leap of faith. The client can’t see what changed. The developer can’t prove what changed. When something breaks, and in any living application something eventually does, there’s no record of which change broke it, no fast way back to the last working version, and a strong incentive for everyone to be vague.
With it, the history is the receipt. Every change is logged: what changed, who changed it, when it shipped, what was tested. When we hand off a project, that history goes with it, in the client’s own repository, because that’s who it belongs to.
This is also why we run the same discipline on our own site that we sell to clients. Our marketing site has no login, no payments, and no database, and it still goes through the full pipeline on every push: type checks, linting, a security audit, and a check that confirms it’s deploying to a Canadian region. Is that overkill for a brochure site? Probably. But “we have release discipline” is a claim, and claims are cheap. The pipeline is the proof.
The numbers: manual deployment vs. a pipeline
A real before-and-after from the kind of operation we build for, a service business maintaining its own line-of-business application:
- Manual deployment: 30–60 minutes of careful hands-on work per release, done rarely because it’s risky. Changes pile up, which makes each release bigger and riskier. A failed release means hours of diagnosis because forty things changed at once.
- Pipelined deployment: the push takes minutes, so changes ship small and often. A failed release means one small change to inspect and a rollback measured in minutes.
The compounding effect is the real story. Teams with safe, fast releases improve their software continuously, because improvement is cheap. Teams with risky, manual releases stop improving, because every change is a gamble. Twelve months later, one application has had fifty small upgrades. The other has had three big scary ones and a growing list of “we should really fix that someday.”
The cost of setting this up at build time, inside a project like ours? Roughly a day of work within a 4–8 week build. The cost of retrofitting it two years later, after the application has grown and nobody remembers the deploy steps? Considerably more, and that’s if anyone bothers.
Three questions to ask any software developer
If you’re hiring anyone to build custom software, us or not us, three questions sort the field quickly.
- “Walk me through how a change gets to production after launch.” The answer should be a process, not a person. If the answer is “I deploy it,” ask what happens when they’re on vacation.
- “If a release breaks something, how do we get back to the version that worked?” The answer should involve a rollback measured in minutes, not a debugging session measured in days.
- “Will I be able to see the history of every change?” The answer should be yes, in a repository you own. If the history lives somewhere you can’t see, so do the problems.
None of these questions require you to know how to code. They’re the same questions you’d ask any contractor: how do you do the work, what happens when something goes wrong, and where’s the paper trail.
The quiet part
CI/CD never shows up in a demo. No client has ever gasped at a deployment pipeline. It’s plumbing, and like plumbing, you only notice it when it’s missing, usually at the worst possible moment, usually expensively.
But it’s also the difference between software that gets better every month and software that calcifies the day the developer’s last invoice clears. A build is not finished when the first version ships. The applications that earn their keep are the ones that keep changing safely. And safety, in software, is not a personality trait. It’s a pipeline.