Before a site goes live, we run through a checklist of common launch-blocking issues — redirects, indexing settings, forms, SSL, key page rendering, broken links — on your staging environment, catching the kind of thing that’s easy to miss under launch-day pressure but painful to discover after the fact.
Pre-launch technical QA checklist run
A pre-launch checklist run on staging — redirects, indexing, forms, SSL, and more.
- Full backup taken before we start
- If we can’t fix it, you get your money back
- We never ask for your own password
What we need from you
- Access to the staging environment about to go live
- Confirmation of your intended go-live date, if known
- Any specific concerns you already have about the build
This or something else?
| You want a structured pre-launch checklist run against your staging site | This fix covers it |
| You already know of a specific issue on the staging site | Worth describing it directly, so it can be prioritised alongside the general checklist |
| The site is already live and you want it checked now | Still covered, though the checklist is specifically designed for a pre-launch context |
| You want a deep, single-topic audit (accessibility, security, performance) instead of a broad launch checklist | The relevant dedicated audit product instead, for genuine depth on that one topic |
What we do
- Confirm the staging environment reflects what’s actually about to launch
- Run through the checklist covering redirects, indexing settings, forms, SSL, key pages, and links
- Flag every item found, distinguishing launch-blocking issues from minor ones
- Fix straightforward, low-risk issues directly where the cause is clear
- Deliver a clear go/no-go summary with anything outstanding
What is included
- A structured pre-launch checklist run against staging
- Launch-blocking issues clearly distinguished from minor ones
- Straightforward issues fixed directly
- A clear go/no-go summary
Not included
- Deep, single-topic audits (full accessibility, security, or performance audits) — separate, more thorough products if genuine depth is needed
- Fixing larger issues found — quoted separately based on what’s discovered
- Managing the actual go-live process or DNS cutover itself
- Ongoing monitoring after launch
Questions about this fix
What kind of things does this checklist actually cover?
Common examples include confirming redirects from the old site are in place, search engines won't index staging by mistake, forms actually submit, SSL is properly configured, and key pages render correctly — the specific list is tailored to your actual build.
Is this a substitute for a full security or accessibility audit?
No — this is a broad pre-launch sweep for common launch-blocking issues, not a substitute for the depth a dedicated audit on any one of those topics provides.
What happens if you find something serious right before launch?
We'd flag it clearly as launch-blocking so you can decide whether to delay or accept the risk, rather than it surfacing as a surprise after go-live.
Can this be run on a live site instead of staging?
Yes, though it's specifically designed with a pre-launch context in mind — running it on an already-live site is still useful, just less urgent in framing.
Will you actually fix everything found before launch?
Straightforward, low-risk issues are fixed directly; anything larger is flagged clearly so you can decide how to handle it before or after going live.
Related fixes
If this is the second time this year
A bad update breaking the site is a symptom of updates not being tested first. Care plans run every update on a staging clone before it reaches your live site, which is the actual fix for this happening again.
Your access, your rules
Create a separate admin account for us and delete it when we are done. For anything else, we get in touch and agree a method — never a form field on this site, never by reply to an email.
We back up first, always
Before anything is touched we take a full backup and keep it for 30 days. If a fix goes wrong, we put the site back exactly as it was.
If it is not what you bought
If the problem turns out smaller than what you ordered, we refund the difference. If it is bigger, we stop and send a quote before doing any extra work.
If we cannot fix it
You get back what we received. Diagnosis is on us — you only pay when the problem is actually solved. The payment processor takes its fee before the money reaches us, so we never hold it and it is not ours to return. That is true here as everywhere else.
If it comes back
Reply within seven days of delivery and we put it back on the bench at no cost. The fix is not finished until it holds.
What we are responsible for
If something goes wrong with a fix, our responsibility is limited to what you paid for it. We take a full backup first so mistakes can be undone, and we tell you before doing anything outside what you bought.