General coding checklist before shipping
Shipping code safely is rarely about one heroic fix. Here, I break down the review, testing and release habits I rely on before I push changes live.
Share
Checking read-aloud support…
A Shipping Checklist Is Mostly About Preventing Boring Failures
Most production problems are not caused by exotic engineering mistakes. They come from ordinary things that nobody checked because the team was trying to move quickly.
A broken route. A form that submits to the wrong endpoint. A JavaScript selector that no longer matches the markup. Metadata that was copied from another page and never updated. A layout that works on desktop and quietly collapses on mobile.
These are not glamorous failures, but they are the ones users actually experience.
That is why I keep a short shipping checklist. It is not there to prove thoroughness. It is there to catch the class of issues that create avoidable cleanup after release.
Check The Paths Before You Check The Polish
The first thing I verify is routing.
If a page cannot be reached cleanly, nothing else matters.
That means checking:
- internal links
- canonical URLs
- redirects or legacy path behaviour
- image and asset paths
- any hardcoded links inside cards, menus or related-content blocks
Static sites and content-heavy sites are especially prone to path drift because content gets reorganised over time. A link that was valid during the first build can become stale after a slug change or folder restructure.
This is also where I look for accidental coupling. If a component only works because it assumes one route shape, that is a maintenance risk.
Verify The Interactive Layer Against The Markup That Actually Ships
A lot of front-end bugs come from JavaScript being written against an older DOM structure.
The code still runs, but not against the page you are now publishing.
Before shipping, I want to know that:
- the selectors still match
- the expected IDs and data attributes still exist
- event handlers still bind once and only once
- no part of the interface depends on a hidden assumption from an old layout
This matters most on pages that have been edited in stages. A menu, accordion, filter, search box or carousel can appear fine at a glance while one key interaction has already drifted out of sync.
In practice, I do not just scan the code. I click through the real interface.
Mobile Failures Are Usually Simpler Than People Think
When something breaks on mobile, it is often not a deep responsive-design problem. It is usually one of a few recurring issues:
- an element overflows because its width was assumed
- a fixed-size asset pushes the layout wider than the viewport
- a heading becomes too long for the container
- a CTA wraps badly and starts looking broken
- a hidden state was never tested on a narrow screen
That is why I always check a small-screen layout before release, even for changes that seem unrelated to layout.
The risk is not only visual. Layout breakage also damages trust. A page that looks unstable reads as less reliable, especially if the site is trying to ask for contact, payment or sign-up actions.
Metadata Errors Travel Further Than People Expect
Content teams often treat metadata as finishing work. It is usually more important than that.
Before publishing, I check that the page title, meta description and social preview values are specific to the page that is actually being shipped.
I am looking for:
- duplicated titles across pages
- vague descriptions that do not describe the actual content
- stale Open Graph images or titles from an earlier draft
- headings and metadata that disagree about the page purpose
This is not only an SEO issue. It is also a clarity issue. When metadata is generic, it usually means the page itself has not been forced to say what it is really about.
Forms Deserve A Real Submission Test
If a page includes a form, I test one real submission path before release.
Not a visual inspection. Not just checking the markup. A real submission.
I want to know:
- does the form submit successfully
- does validation behave as expected
- does the success state appear
- does the data reach the right place
- is there an obvious recovery path if submission fails
Forms are a classic example of something that can look complete while being broken at the exact moment it matters most.
If a site exists to generate enquiries, a broken form is not a minor bug. It is the main failure.
Performance Checks Should Focus On Obvious Waste
I do not try to turn every release into a full performance audit.
What I do check is whether the page has picked up obvious waste during the work.
That usually means looking for:
- large images where smaller ones would do
- scripts loaded on pages that do not need them
- duplicated assets or dead dependencies
- render-blocking patterns introduced by convenience
The point is not to chase perfect scores. It is to avoid shipping something clearly heavier than it needs to be.
Rollback Is Part Of The Release, Not A Separate Concern
One of the fastest ways to improve release quality is to think about repair before the release goes live.
If something fails after publishing, I want to know how quickly I can put the site back into a stable state.
That means having a clear answer to:
- what previous version can be restored
- how long rollback would take
- whether content or configuration changed alongside the code
- which pages or services are most exposed if the release is bad
Teams often call this “being safe,” but it is really about reducing decision latency. If the repair path is obvious, incidents stay smaller.
A Checklist Should Stay Short Enough To Be Used
The best shipping checklist is not the longest one. It is the one that gets used every time.
Mine stays intentionally small because I want it to remain operational under pressure. If a checklist becomes too detailed, people stop trusting it as a final gate and start treating it like documentation.
A useful checklist should cover the failure modes you see repeatedly in real work.
For me, that means:
- validate links and route paths
- verify scripts against shipped markup
- test mobile layout and overflow behaviour
- confirm metadata is page-specific and clear
- test one real rollback or recovery path
That list is not exhaustive. It is practical.
Reliable Shipping Is Usually Quiet Engineering
There is a tendency in software work to celebrate complexity and underestimate routine discipline.
But most stable releases come from quiet engineering habits rather than clever last-minute fixes.
A shipping checklist is one of those habits.
It does not guarantee that nothing will go wrong. What it does is reduce the number of failures that never should have reached production in the first place.
