Software Production Readiness Check

It Works. But Is It Ready for People to Depend on It?

A practical self-assessment for applications, websites and AI-built software moving from working prototype to real-world use.

Getting software working is an important milestone. Production introduces a different set of questions.

Who can access the data? What happens when something fails? Can you recover it? Will you know when production is breaking? Can somebody safely change the code six months from now?

Use this assessment to identify the areas that look healthy, the ones worth checking and anything that may deserve attention before the software becomes more important.

Who this is for

When Working Software Starts Becoming Important Software

You do not need a traditional development project for production readiness to become relevant.

You Built It With AI

ChatGPT, Claude, Codex, Lovable, Replit or another AI-assisted workflow helped you get something useful working quickly and you now want to know what may have been missed.

The Prototype Became the Product

Something originally built to prove an idea is now being used by employees, customers or partners.

You Are About to Launch

The functionality is there, but you want a better view of whether the operational foundations are ready too.

You Inherited the Application

You are now responsible for software somebody else built and need to understand which areas deserve closer investigation.

Production readiness assessment

How Ready Is Your Software?

Answer based on what you know today. If you do not know the answer, choose Not Sure. Uncertainty around an important control is useful information in itself.

0 of 8 areas completed

Security & Access

Can the right people access the right things, and are obvious security responsibilities under control?

Where login is required, does the application use an established authentication approach rather than custom password or session handling?
Not ApplicableNoNot SurePartlyYes
Are permissions enforced on the server for sensitive actions and data, rather than relying only on what the interface hides?
Not ApplicableNoNot SurePartlyYes
If different customers, organisations or users have private data, have you verified that one cannot access another's records?
Not ApplicableNoNot SurePartlyYes
Are passwords, API keys and other secrets kept out of source code and public repositories?
Not ApplicableNoNot SurePartlyYes
Do you have a way to identify known security issues in packages and dependencies?
Not ApplicableNoNot SurePartlyYes

Read the result carefully

A High Score Does Not Cancel a Serious Red Flag

Production readiness is not an average of thirty unrelated questions.

An application could have excellent testing, documentation and monitoring while still exposing one customer's data to another customer. That security issue matters more than the overall percentage.

The assessment therefore highlights critical answers separately from the general readiness score.

What the assessment cannot know

The Difficult Questions Need Evidence From the Actual System

Self-assessment is useful for finding gaps in what you know. It cannot verify whether the controls you believe are present actually work.

Whether Permissions Really Work

The interface may appear restricted while an API or database policy still allows access that should not be possible.

Whether the Code Is Maintainable

A working application can hide duplication, unsafe patterns and architectural problems that only become obvious when the repository is reviewed.

Whether Production Is Configured Safely

Hosting permissions, database exposure, secrets, backups and environment settings need to be checked where they actually run.

Whether Recovery Really Works

Having a backup configured is different from knowing that the business can recover from it when needed.

If the result raises concerns

Move From Self-Assessment to Evidence

You do not need to rebuild the application because a checklist found gaps. Investigate the important ones first.

  1. 01

    Identify

    Use the assessment to see which areas are weak, unknown or potentially important.

  2. 02

    Investigate

    Check the code, live application, hosting and data environment to establish whether the concern is real.

  3. 03

    Prioritise

    Separate launch blockers and material risks from improvements that can safely happen later.

  4. 04

    Strengthen

    Fix the areas that matter without unnecessarily replacing useful work that is already sound.

Need a proper technical review?

A Technical Audit Goes Beyond What You Can See From a Checklist

If the application is important enough that the unknowns need verifying, Structurell can inspect the actual repository, live application and production environment.

The audit investigates security, maintainability, architecture, reliability, performance, data, integrations, testing, deployment, hosting and relevant production settings, then prioritises the findings based on what actually matters.

Evidence, Not Assumptions

Check whether the controls and concerns identified by the self-assessment exist in the actual system.

Prioritised Findings

Separate material risks from automated noise and lower-value improvements.

Indicative Effort

Understand the likely level of work involved in addressing meaningful findings.

Your Choice of Delivery

Fix items internally, use another supplier, ask Structurell to implement them or take a hybrid approach.

Built something worth keeping?

You Do Not Need to Start Again to Make It Production-Ready

If the software already solves a useful problem, the sensible route is usually to understand the gaps, fix the ones that matter and keep the good work that is already there.