Your developer says “we’ll deploy it tonight.” You say yes. Then your site is down at 9 a.m. and the same developer says the word “rollback” like it is someone else’s job.
Deployment (the moment new code replaces old code where customers can reach it) is the most under-priced risk in small business software. Not because deployments are usually bad. Because the ones that go wrong go wrong in public, and the difference between a bad afternoon and a lost week is decided before the deploy, by questions nobody asked.
What a real pipeline has
A pipeline is the road code travels from a developer’s keyboard to your customers. A real one has four checkpoints:
- Automated checks before shipping. Machine-run tests and validations that block the release when they fail, no override by mood. Our own site’s rule is written in its public repository: lint, typecheck, test, build, all green or nothing ships (github.com/Anito-Systems-Solution/anito-main-web, AGENTS.md). The list is short and the discipline is the point.
- A test environment you open yourself. A private copy of the site where you click the new feature before any customer can. Not screenshots. Not a developer’s screen share. A link you control.
- A rollback that is measured in minutes. Putting yesterday’s version back, rehearsed, not improvised. If nobody knows how long a rollback takes, the answer is “as long as the outage lasts.”
- Keys held in the right name. Hosting, repository, accounts. Yours, from day one. An agency that holds your keys owns your exit price.
Containers, since the quote will mention them
The word you will hear in every deploy conversation is container. The plain version: the application and everything it needs to run get sealed into one box with its own fittings, and the box runs the same on a laptop, a test server, or production. Two things that buy you as the payer. The “it worked on the developer’s machine” conversation mostly dies, because the machine travels with the app. And rollback turns mechanical: yesterday’s box still exists, so going back is a switch, not a rebuild. Our own site ships this way, and the box recipes sit in the public repository next to the code they run. When a quote mentions containers, ask the only question that matters about them: who builds the box, and where is yesterday’s box kept?
What 2025 and 2026 proved
This is not theory. The year’s incidents wrote the checklist in public.
The “Shai-Hulud” attack compromised more than 500 npm packages (the shared code libraries modern software is assembled from) and harvested credentials; a US government alert followed with the mitigations, and the first one is pinning your dependencies so a poisoned update cannot walk in (CISA alert, September 2025). A second wave in August 2026 hit more than 440 packages with over two billion combined downloads (Sygnia). Two waves in a year means “what code libraries does my software pull in, and are they pinned?” is a board-level question now, not a developer detail.
Then the platforms themselves: Cloudflare’s global outage in November 2025 took down a long list of household names for over five hours, and the company’s own postmortem traced it to a configuration file and a permissions change, not a hacker. Weeks earlier, AWS’s biggest region had its worst outage in years. The internet’s biggest platforms failed on process, not machinery. If they are not immune, your answer is not “pick the safe platform.” It is “know your rollback and your exposure before the day.”
The four questions
- “What happens if a deploy goes wrong at Friday, 5 p.m.?” You want the rollback story, with a number of minutes in it.
- “What runs before code ships, and can it block a release?” You want named checks, and you want to hear that a red check stops the train.
- “Where do I click to see the new feature before my customers do?” You want a test environment link, and you want it in your name.
- “Whose name are the repository, hosting, and accounts in?” The answer to this one is in your contract now, not in the handover later.
Deploy discipline is also why we publish a ownership checklist to settle before invoice one: the deploy questions are exit questions wearing work clothes. If a current build has you uneasy, our process page shows what we put in writing before anything ships. To put your project against this checklist, discuss your project with us.
Common questions
How often should deployments happen?
Small and often beats big and rare, because a small change that breaks something is found in minutes and rolled back in minutes. A three-month release is a three-month backlog of untested-together changes deploying at once. The rhythm we use on our own site is: gated changes shipped as they are ready, each one small enough to read and reverse.
What is a rollback, exactly?
Putting the previous version back so the business keeps running while the problem is investigated. A real rollback is rehearsed and measured in minutes, because the old version still exists and switching to it is mechanical. If a developer has to “figure out” a rollback while your checkout is down, that improvisation is the outage.
Do these questions matter if we use a big hosting platform?
They matter more. Cloudflare’s November 2025 outage and AWS’s October 2025 outage were platform-wide, traced to process and configuration, and no customer of either could do anything about them mid-incident. Your controls are the ones on your side of the fence: what you ship, how fast you can reverse it, and whether your own dependencies are pinned.
What is dependency pinning, in plain words?
Fixing the exact version of every shared code library your software uses, instead of floating on “whatever the latest is.” The Shai-Hulud attack moved through packages by publishing poisoned new versions; pinned projects did not catch it because they never asked for the new version automatically. It is the software equivalent of refusing packages you did not order.