Until it happens, the work may be built, but it’s still sitting in the back room. That’s the line between development (building and testing) and deployment (moving the built thing into the environment where it runs for real): publishing a website, updating an internal tool, or pushing a change to the cloud.
Think about opening a small office. You can design the forms, arrange the desks, test the printer, and train the staff before anyone walks in. Deployment is the moment you unlock the front door and let real people use the place.
How it shows up
Deployed isn’t the same as done. The stakes change: a mistake that was harmless on your laptop can hit a client once it’s live. This is why teams separate staging and production, the practice office versus the real one people depend on. You’ll also hear CI/CD, the pipeline that checks, builds, and ships changes repeatably. With AI tools, deployment is where you slow down. Claude or Codex can change things fast, but quick changes still need a path to real use: what changed, was it tested, who can see it, can you undo it? That undo path is a rollback, and you don’t want to design it while the tool is already broken in front of users.
Why you care
AI makes building feel faster than shipping discipline. You can generate a lot of code in an afternoon, but the business only benefits when the right version is live, stable, and recoverable. Deployment is where software leaves the workbench and becomes part of the real operation.