Nzubechukwu.
← All posts
Software engineering5 min read

Deploying on Friday: a risk framework, not a superstition

'Never deploy on Friday' is a slogan. What you actually need is reversibility, monitoring, and an honest blast radius.

By Nzubechukwu Cyprian · Pharmacy student at UNN, full-stack developer

Cover image for “Deploying on Friday: a risk framework, not a superstition” — Software engineering

Every developer hears "never deploy on Friday." It's decent folk wisdom, but it's a superstition standing in for a missing framework. What Friday actually signals is: you're about to leave the code unwatched. The real question isn't when — it's how bad is it if this goes wrong while nobody's looking.

The three questions I ask before any deploy

Can I undo it in one command? If a deploy is a git revert away from safety, its worst case is minutes. If rollback means archaeology, its worst case is a weekend. Reversibility decides more than the calendar.

What's the blast radius? A copy change and a database migration do not belong in the same risk category. I sort every change into: cosmetic, behavioural, data-touching. Data-touching changes get backups, dry runs, and daylight hours — regardless of the day.

Will anyone be watching? If I'm around for the next hour, a Friday afternoon deploy is fine. If the next pair of eyes is Monday, the deploy waits — not because Friday is cursed, but because silence is.

The honest version of the slogan

Deploy small, deploy reversible, deploy watched. Do all three and Friday is just a day. Skip them and Tuesday will burn you anyway.

Found this useful? Send it to someone.

Nzubechukwu Cyprian studies Pharmacy at the University of Nigeria, Nsukka and builds software, products, and AI experiments in between.

One email when a post lands

No schedule, no spam. Just the posts worth reading — new writing on software, AI, products, and the Pharmacy × Tech life.

Prefer a feed reader? Grab the RSS feed.