When Every Deployment Is a Different Story: The Ad Hoc Delivery Trap

You have a small team. Maybe five or six people. The app works. Users are happy. Deployments happen, but nobody really talks about how. One developer copies files to the server using FTP. Another runs a script from their personal laptop. A third just logs into production and makes changes directly.

Nobody complains, because things mostly work. Until they don't.

The person who "knows how to deploy" goes on leave. A critical bug needs to go out, and nobody else can figure out the steps. The deployment takes three hours instead of twenty minutes. Someone runs the wrong SQL command against the production database. There is no way to undo it.

This is Level 1 of delivery maturity: Ad Hoc. Everything is manual. Everything is different every time. And the entire process depends on who is available, not on what is documented or automated.

The Individual Dependency Problem

The clearest sign of an Ad Hoc delivery process is that knowledge lives inside people's heads, not in any shared system. When one person holds the deployment knowledge, that person becomes a bottleneck. If they are on leave, deployments stop. If they leave the company, the knowledge leaves with them.

Even when documentation exists, it is usually outdated. Someone wrote a README six months ago. Since then, the deployment steps have changed five times. Nobody updated the document. New team members learn by trial and error, asking whoever seems to know what they are doing.

The following flowchart illustrates how an ad-hoc deployment can branch into unpredictable paths, each with its own risks:

flowchart TD A[Developer starts deployment] --> B{Which method?} B --> C[FTP files to server] B --> D[Run personal script] B --> E[Direct edit on production] C --> F[Files may be incomplete] D --> G[Script only works on one machine] E --> H[Risk of wrong SQL command] F --> I[Deployment fails silently] G --> J[Another dev cannot run it] H --> K[No rollback possible] I --> L[Person on leave - no fix] J --> L K --> L L --> M[Deployment takes hours]

This is not about incompetence. Small teams often survive this way because the stakes are low. But as the team grows, the cracks become visible. Every deployment becomes a new adventure. Nobody can predict whether it will take ten minutes or two hours.

Manual Deployment: No Two Are the Same

In an Ad Hoc environment, there is no standard deployment procedure. Each developer has their own method. One person might SSH into the server, pull the latest code, and restart the service. Another might upload a zip file through a web interface. A third might run a local script that only works on their machine.

Because there is no single source of truth, nobody can verify whether the deployment was done correctly. When something fails, the person deploying starts guessing. They try different commands, restart services, check logs, and hope something works. If they get stuck, they call someone else who might know more.

This approach works when you deploy once a month. It becomes painful when you need to deploy weekly or daily. Every deployment carries the same risk, because the process is never refined. Mistakes repeat. Time is wasted rediscovering the same solutions.

Database Changes Without a Safety Net

Database management at Level 1 is particularly dangerous. Schema changes are applied directly to the production database. A developer logs into the database server, runs an ALTER TABLE statement, and hopes nothing breaks.

There are no migration scripts. No version tracking. No rollback plan. If the change causes issues, the same developer must figure out how to reverse it, often by running another manual SQL command that might or might not work.

The team has no way to know which version of the schema is currently running. If two developers make changes at the same time, conflicts go undetected until something breaks. Production data can be lost, corrupted, or left in an inconsistent state.

Infrastructure Managed by Memory

Servers are set up manually. Someone logs in, installs packages, configures services, and adjusts settings by hand. Application configuration lives in files on the server, not in version control. If a server dies, the team must remember every step needed to recreate it.

There is no Infrastructure as Code. No automated provisioning. No repeatable setup process. The team relies on memory, sticky notes, and the goodwill of whoever set up the original server.

This works when you have one or two servers. It becomes unmanageable when you need to scale, recover from failures, or replicate environments for testing.

Why Teams Stay at Level 1

Staying at Level 1 is not a sign of laziness or lack of skill. Many teams remain here for valid reasons:

  • The team is very small, and manual processes are fast enough.
  • Deployments happen infrequently, so the pain is not constant.
  • The application is not critical, so failures have low impact.
  • The team has other priorities that feel more urgent.

These reasons make sense in the short term. But they create hidden costs. Every manual deployment carries risk. Every undocumented step creates dependency. Every direct database change increases the chance of data loss.

The problem is not that the team is doing something wrong. The problem is that the current approach does not scale. When the team grows, when deployments become more frequent, or when the application becomes more critical, the Ad Hoc process becomes a liability.

The First Step Is Not Buying a Tool

Moving beyond Level 1 does not require expensive tools or complex pipelines. The first step is simpler and harder: acknowledge that the current process is unreliable, and start documenting what actually happens during a deployment.

Before you automate anything, you need to know what you are automating. Before you build a pipeline, you need to agree on the steps. Before you buy a CI/CD platform, you need to understand your own workflow.

Practical Checklist for Moving Beyond Ad Hoc

If you recognize your team in this description, here is where to start:

  • Write down the exact steps for a deployment, including every command and every decision point.
  • Identify who holds critical knowledge and what happens when that person is unavailable.
  • List every manual step that could cause a failure if done incorrectly.
  • Document the current database schema and how changes are applied.
  • Record the server setup process, including all packages, configurations, and dependencies.

This is not about creating perfect documentation. It is about making the invisible visible. Once the process is written down, you can see where the risks are and where automation will actually help.

The Concrete Takeaway

Ad Hoc delivery works until it doesn't. The moment a deployment fails and nobody knows how to fix it, or the person who knows is unreachable, the cost of manual processes becomes clear. The path forward is not about tools or automation yet. It is about admitting that the current way is fragile, and starting to write down what you do so you can eventually do it better.