Webflow Design Agency London: The Checks to Run Before Launch

Introduction

Launch day arrives and somebody asks whether the site is ready. What follows is usually a room of people saying it looks good, which is not an answer, because nobody has said what ready means. Two weeks later the form is going to an inbox nobody reads, a section is missing on phones, and the person who spots it is a customer. None of that was a build failure. It was a sign-off that had no criteria in it.

Key Takeaways

• Define Ready Before You Need It: Agree the launch criteria weeks before the launch date.
• Give Every Check An Owner: A list with no names beside it gets skipped.
• Test Forms End To End: Submit one and confirm a human receives it.
• Automated Passes Are Not Proof: Tools miss issues that only real people find.
• Test On Real Devices: A mid-range phone finds what a designer’s laptop hides.
• Accessibility Is A Legal Duty Here: UK businesses must make reasonable adjustments, not intend to.

What Does Ready to Launch Actually Mean?

It means a written list of checks, each with a name against it, agreed before the date is set. Without that, sign-off defaults to opinion, and opinion is why launches ship with broken forms and missing mobile content. Looks good is not a launch criterion; it is the absence of one.

Five signs your sign-off has no criteria in it, all of which you can spot in your next launch meeting.

1. Nobody can say what would stop the launch.
2. The checks live in someone’s head rather than in a document.
3. Testing happens on laptops, in the office, on office wifi.
4. Nobody has submitted a real form and waited for the email.
5. The launch date was fixed before anyone listed what had to be true.

If three of these are familiar, the risk is not that something breaks. It is that it breaks quietly and stays broken, because nobody was ever assigned to look.

Here is what that costs in practice. A site goes live with the contact form still pointing at an old address. Everything looks correct from the outside, so nobody investigates, and the first evidence of a problem is a customer asking on the phone why their enquiry was ignored.

Which Checks Belong on the List?

Five groups of them, and the point is that they are written down rather than remembered. A Webflow design agency London teams have used before brings that list to the kick-off meeting, not to the launch one. Webflow’s pre-launch checklist organises the work into design and content review, functionality and QA, then search, accessibility and performance, then external tools and integrations, and finally staging and publishing readiness. Having that structure matters commercially: it turns your sign-off meeting from a discussion into a list somebody either completed or did not.

The checks that catch the most expensive failures are these.

6. Submit every form and confirm a person receives the message, on the address that will be live.
7. Click every navigation item and every call to action, including in the footer.
8. Open the site on a real mid-range phone and complete one full task.
9. Confirm mobile carries the same content as desktop, not a shortened version.
10. Check analytics and event tracking actually fire, before the traffic arrives.
11. Confirm redirects are in place for any URL that changed.

Run those six and you have removed most of the failures that get discovered by customers rather than by the team.

Two Mistakes That Cost You Later

One of these is a decision you make, the other is one you allow.

12. Fixing the launch date before agreeing the criteria. Once the date is public, every unfinished check becomes a negotiation, and the checks lose.
13. Testing only the pages, never the journey. Individual screens can each be fine while the path through them is impossible, and only a task test finds that.

Why Is an Automated Pass Not Enough?

Because tools check what can be checked automatically, which is a narrow slice of what people struggle with. Passing an audit tells you the obvious errors are gone. It does not tell you the site is usable.

the GOV.UK accessibility testing guidance is blunt about this, saying it is important to do both automated and manual testing because you will miss some issues if you only do the automated kind, and recommending testing with disabled users and older users as part of meeting the standard. In practice this means an accessibility report is evidence of effort rather than evidence of an accessible site, and the difference is one your buyers and their procurement teams increasingly know how to ask about.

Three things to add to whatever the tools produce:

14. A keyboard-only pass through the main journey, with no mouse.
15. One task test with someone who has never seen the site.
16. A check of contrast and focus states on the templates, not only the homepage.

None of those three take long. A keyboard-only pass through one journey is ten minutes of work, and it surfaces problems no automated report will show you.

For a UK business this is not only good practice. The Equality Act 2010 makes reasonable adjustments an ongoing duty, so accessibility is a standing obligation rather than a launch task, and the checks above are the cheapest way to keep it honest.

What Does London Change About the Sign-Off?

Mostly the number of people in the room, and how quickly they can be got there. That is a real advantage and it is worth using deliberately rather than assuming proximity does the work by itself.

17. More stakeholders. Enterprise and finance buyers here often need marketing, sales, legal and sometimes compliance to agree, and an hour in a room beats three weeks of comments.
18. Procurement timing. Requirements arrive late from legal or procurement, so ask for them before the build rather than during sign-off.
19. Consent affects your baseline. If your cookie banner is strict, some of your launch analytics simply will not be there, so record what you can measure before you change anything.

A pro tip: run the sign-off session on phones, with everyone using their own device, rather than on a shared screen. The problems people find in five minutes that way are the ones customers would have found in the first week.

Whether you engage a studio or a Webflow designer UK based for part of the work, ask them to walk you through their checklist and name who signs each line. Anyone who has launched sites before will have one ready.

Spoke’s UK Webflow work shows the kind of build these checks apply to.

Conclusion

Launches do not usually fail on the build. They fail on a sign-off with no criteria, where everyone assumed someone else had checked the thing that later broke. Write the list before the date is fixed, put a name against every line, submit a real form, complete one real task on a real phone, and treat an automated pass as a starting point rather than a verdict. A Webflow design agency London businesses trust will bring that list to the first conversation rather than the last. If you want a second opinion on a launch checklist before you commit to a date, Spoke works on Webflow design and development for UK teams, and is happy to review the list whether a studio or a Webflow designer UK based is doing the build.

FAQs

Q. What is the single most important pre-launch check?

Ans. Submit every form on the live configuration and confirm a person receives the message. It is the failure that costs the most and gets noticed the latest, because everything looks normal from the outside while enquiries quietly go nowhere. Test the address that will actually be in use.

Q. Is an accessibility tool report enough evidence?

Ans. No. GOV.UK guidance states that you will miss some issues if you only do automated testing, and recommends testing with disabled and older users as well. Treat a clean report as the floor, add a keyboard-only pass and one task test, and specify the standard you expect in the contract.

Q. How long before launch should the checklist be agreed?

Ans. Before the launch date is fixed, not after. Once a date is public, unfinished checks turn into negotiations and the checks tend to lose. Agreeing the criteria early also changes what gets built, because the team knows from the start what it will be measured against.