Websites and software that keep working after launch

The expensive mistake in software is building the wrong thing competently. So the first output of a project is not code but a written description of the job: who uses it, what they do today, what has to keep working when something else fails, and what the business will do without it. Anything that cannot be explained at that stage is a sign the piece of work should be smaller, not larger.

Code, accounts, hosting and documentation are held in your name, and the way a system is deployed is written down while the person who built it is still reachable. A supplier whose systems only they can operate has not built you a system so much as a dependency.

• Repository, hosting and third-party accounts in your name
• Written notes on how it is built, deployed and restored
• A handover session with the people who will use it

We test the things that are easy to claim and hard to prove: how heavy a page is on a phone, whether it can be used with a keyboard or a screen reader, whether the forms actually deliver, and whether the site still behaves when a script fails to load. Where something does not pass, it is fixed or disclosed rather than described as best practice.

• Page weight and loading behaviour on a mid-range phone and an ordinary connection
• Keyboard access, contrast and the basics a screen reader needs
• Forms, redirects, and what the site tells a search engine about itself

A launch is a date, not an ending. Support is agreed in writing before the work starts: what is covered, which response window applies, how a change is requested, and what counts as new work rather than maintenance. Where the studio looks after a site, the arrangement is reviewed at the interval agreed instead of running unattended.