Skip to content
P→Productionise
Check my site

What Is Production Readiness?

Production readiness means having enough evidence, safeguards and operational control to let real customers depend on a website or application. A prototype can demonstrate the idea beautifully while still needing work around security, reliability, accessibility, ownership and recovery.

Reviewed
Reading time
11 min read
Category
Production Readiness

In Plain English

A prototype proves that an idea can work. Production readiness asks whether real customers can use it safely and reliably, and whether the business can keep it running when ordinary problems occur.

Think of a new shop that looks finished from the street. Before opening, it still needs working locks, payment arrangements, safety checks, stock procedures and a plan for an outage. A website needs the digital equivalent: sensible security, testing, ownership, monitoring and recovery. The checks should match what the website does and the consequences if something fails.

Key Takeaways
  • A convincing prototype and a production-ready system answer different questions.
  • Readiness combines engineering evidence with operational ownership.
  • The right controls depend on the customer journey, data and consequences of failure.
  • Launch should include monitoring, recovery and a documented rollback path.
Detailed guide contents

Engineering-led guidance. This guide draws on Productionise's standards and practical engineering experience. Examples are generalised to protect confidentiality.

What production readiness means

Production readiness is a decision supported by evidence, not a badge added when the pages look finished. The relevant standard depends on what the system will do: a brochure site, an enquiry form and an authenticated service carry different risks.

During production-readiness reviews, we commonly find that the visible customer journey is further advanced than the controls behind it. That is normal for a prototype. The next step is to identify what matters before public use and verify it deliberately.

  • The intended customer journey works in realistic conditions.
  • Important failure modes have been considered and tested.
  • The business controls the accounts, code and recovery paths it depends on.
  • Known limitations have an owner and a practical treatment.
See how Productionise reviews a prototype

Why working is not the same as ready

A prototype answers: can this idea work? Production software must also answer: can customers use it safely and consistently, can the business operate it, and can it recover when something goes wrong?

This distinction does not mean AI-built or DIY websites are inherently unsafe. These tools are excellent at making ideas tangible quickly. Production work adds the controls that rapid prototyping quite reasonably leaves until later.

The technical foundation

The technical foundation covers the behaviour customers experience and the safeguards they cannot see.

Security and privacy

Separate public configuration from secrets, validate untrusted input on the server, restrict access to what each service needs and avoid logging sensitive information. HTTPS protects data in transit, but it is only one part of the security model.

Reliability, performance and accessibility

Test important journeys across realistic devices and failure conditions. Keep pages responsive and understandable, provide keyboard access and semantic structure, and remove unnecessary work that slows the experience. No single architecture is always fastest; measurement should guide improvements.

Technical SEO and analytics

Technical SEO removes common crawling and indexing barriers through useful rendered content, metadata, canonical URLs, internal links, a sitemap and sensible robots rules. Analytics can show aggregate behaviour when configured carefully, but neither implementation guarantees rankings or commercial outcomes.

The operational foundation

A site remains production-ready only when someone can operate it. Monitoring should detect material failures. Backups need a usable restore path. Documentation should explain the system well enough for another responsible person to act.

  • Monitoring covers availability and critical customer journeys.
  • Backups exist outside the system they protect and restoration is tested.
  • Cloud, domain and source-control ownership is clear.
  • Deployment and rollback steps are documented.
  • Dependencies and routine maintenance have an owner.
Understand Productionise's ownership approach

Making the launch decision

Launch is a risk decision, not a claim that the system is perfect. Critical issues should block launch. Lower-severity limitations may be acceptable when they are understood, recorded and assigned to an owner.

A sensible launch plan defines the release being approved, the evidence reviewed, who can make the decision, how to roll back and what will be checked after launch.

  • Scope and customer journeys are agreed.
  • Security and privacy controls match the data handled.
  • Responsive, accessibility and failure-path tests have been completed.
  • DNS, HTTPS, hosting and deployment are verified.
  • Technical SEO and privacy-conscious measurement are checked.
  • Monitoring, backup, recovery and rollback arrangements are usable.
  • Accounts, source code and documentation are controlled by the business.
  • Known risks and post-launch owners are recorded.

Should I care?

This matters if…

  • The website is about to become publicly available.
  • Customers can submit information or the business depends on the site working.
  • The owner is unsure who controls the code, domain, hosting or recovery access.

It may not be urgent if…

  • The prototype is still a private experiment with no real customer access.
  • The business is testing the underlying idea and expects the current version to be replaced.

Continue reading

Have a question about this guide?

Use the existing contact form and include the guide title with your question.

Contact Productionise