Detailed guide contents
Engineering-led guidance. This guide draws on Productionise's standards and practical engineering experience. Examples are generalised to protect confidentiality.
Ownership and source control
The business needs practical control, not just permission to view a project.
- Business-controlled accounts own the domain, DNS, source repository and production cloud resources.
- Source and required assets can be exported without depending on a personal account.
- The production branch is identifiable and protected from accidental changes.
- Third-party code, fonts and media have acceptable licences.
- Recovery access is held securely by more than one authorised person where appropriate.
Secrets, authentication and authorisation
Treat browser code as public. Protect credentials and verify access on the server.
- No password, API key, private token or connection string is in source control or the static build.
- Environment names and responsibilities are documented without recording secret values.
- Authentication proves identity where required.
- Authorisation checks what each authenticated person may do.
- Administrative access uses least privilege and multi-factor authentication where supported.
- Production fails safely when required protected configuration is missing.
Forms and untrusted input
Anything submitted by a browser can be malformed or automated, even when the interface looks controlled.
- Required fields and formats are explained before submission.
- The server validates length, type and allowed values independently of the browser.
- Abuse and rate controls match the likely risk.
- Errors are useful to customers without exposing internal details.
- Only necessary personal information is collected and retention is understood.
- Successful live delivery and a failure path have been tested.
DNS, HTTPS and hosting
Domain and hosting choices affect availability, ownership and recovery.
- The intended canonical domain resolves to the controlled production service.
- HTTP and alternate hostnames follow the documented redirect policy.
- HTTPS certificates are valid for every public hostname.
- DNS changes preserve mail and verification records.
- Hosting behaviour matches the application, including redirects and error routes.
- Expected usage, support needs and provider pricing have been considered.
Security, dependencies and testing
A production baseline combines configuration, code review and realistic testing.
- Security headers are appropriate for the site's resources and integrations.
- Dependencies are necessary, supported and reviewed for known vulnerabilities.
- Debug routes, preview data and development exceptions are absent from production.
- Critical journeys have positive, negative and failure-path tests.
- A production build completes using the supported runtime.
- Live responses do not expose secrets, stack traces or sensitive source maps.
Mobile, accessibility and performance
Real customers use different devices, input methods and network conditions.
- Layouts work at representative phone, tablet and desktop widths.
- Navigation and controls work with a keyboard and have visible focus.
- Pages use one clear H1 and logical heading order.
- Forms have associated labels, help and errors.
- Colour contrast, touch targets and reduced-motion preferences are considered.
- Images have appropriate dimensions and alternative text.
- Performance is measured before making architecture claims.
Technical SEO and analytics
Discovery and measurement need accurate configuration, not ranking promises.
- Every indexable page has useful rendered content and unique metadata.
- Canonical URLs use the production origin consistently.
- Sitemap entries map to real indexable pages and robots.txt declares the sitemap.
- Important pages are linked through crawlable, descriptive anchors.
- Structured data describes only visible and evidenced information.
- Analytics loads only where intended and avoids personal form data and sensitive query values.
- Search and analytics provider settings have been verified separately from code.
Monitoring, backup and recovery
The launch team should know about failure and be able to respond.
- Monitoring covers the homepage, certificate and critical customer journey.
- Logs are useful without intentionally retaining sensitive content.
- Backups cover source, essential configuration and business-controlled records.
- At least one meaningful restore has been tested.
- Recovery priorities, owners and communication paths are documented.
- Provider outages and contact-form delivery failures have practical workarounds.
Documentation, launch and rollback
A controlled release is identifiable, reversible and handed over.
- Architecture, data flow and configuration names are current.
- Deployment and rollback instructions have been exercised.
- The exact release and approval evidence are recorded.
- Critical issues block launch; accepted limitations have owners.
- Live routes, forms, metadata, HTTPS and error behaviour are checked after deployment.
- 24-hour and seven-day reviews are scheduled where appropriate.
- Ongoing maintenance and platform review responsibilities are assigned.
Should I care?
This matters if…
- A launch date is being discussed or customer access has already begun.
- You need to understand what remains before approving a release.
- There is no single record of tests, risks, rollback and operational ownership.
It may not be urgent if…
- The site is an internal mock-up with no connected production services.
- The customer journey is changing so substantially that detailed launch evidence would immediately become obsolete.