Your AI-built app needs more than a working demo

Those responsibilities apply however the code was written. The practical question is whether the people running the service understand what they have, what could go wrong and who will act when it does.

Follow the work beyond the screen

Start with a complete journey. Who makes the request? What information do they provide? Who decides what happens next? Where does the result go?

Ask the team to demonstrate that journey using test data, then introduce an awkward case. Leave a required field blank. Submit the same request twice. Change something after it has been approved. Make a connected service unavailable in the test environment.

Check what the user sees and what the system records. A reassuring confirmation on screen should correspond to a completed action, or clearly explain what is still pending. If someone must resolve an exception manually, make that handover visible.

Understand the system you already have

Before adding another feature, ask the builder to explain the existing structure in plain English: the main records, the rules governing them, the connected services and the places where important decisions happen.

Look for reuse. Does the new feature need another customer record, or should it use the one that already exists? Is the same approval rule being implemented in several places? Who decides which version is correct?

The NCSC’s guidance on maintainable code treats understandable, maintainable software as part of secure development. For a business owner, a useful test is whether another competent developer can explain and change the app without reconstructing every decision from old conversations.

Keep an up-to-date system overview, setup instructions and a short record of significant decisions. Proportionate documentation gives the next person somewhere reliable to start.

Test access with different people in mind

Write down who should be able to see, create, change, export and delete each type of record. Test those permissions with separate accounts representing the actual roles, including somebody whose access has been removed.

A hidden button is insufficient evidence that an action is restricted. Ask a qualified reviewer to check that the underlying service enforces the intended permissions. Make sure the review covers connected services and administrative access as well as ordinary screens.

OWASP’s Application Security Verification Standard provides a structured basis for technical security verification. Agree which checks suit the app’s information, users and consequences. A short checklist or an AI’s assurance cannot establish that an application is secure.

Give failure a practical rehearsal

Consider a fictional bookings app for a small events team. The demonstration lets a colleague reserve a place and see a confirmation. Before launch, the team also needs to know what happens when two people request the final place, a notification fails or an organiser cancels a session.

It should be possible to distinguish a confirmed booking from a pending request. The team needs a way to find affected people, correct records and explain what happened. These are proposed test cases, not findings from a client project.

Rehearse recovery with suitable test data. Demonstrate how a backup is restored, how a failed change is reversed and how the team keeps working while the app is unavailable. Record what was tested and anything left unresolved. Set acceptable recovery targets around the consequences of interruption.

Make the launch decision explicit

Bring the evidence together in a short readiness review:

• Purpose: the intended users and the job the app must help them finish

• Journeys: normal, difficult and failure cases tested, with results recorded

• Information: agreed records, retention needs and responsibilities

• Access: role and permission checks appropriate to the app’s risk

• Usability: feedback from intended users, including accessibility needs and relevant devices

• Operations: monitoring, support, recovery and an owner for each

• Maintenance: controlled releases, dependency updates and a usable handover

• Decision: proceed, run a limited pilot or resolve named gaps first

The NCSC’s development and deployment guidance covers security throughout development and ongoing management. Use that broader view when agreeing what your own team and any supplier will each look after.

A limited pilot can be a sensible next step, with clear limits on users, data and actions. Decide in advance what evidence would justify wider use and what would make you pause. Name the person who can make that call.

Building a useful app includes the work of running it. Give that work an owner and a place in the plan before the demonstration becomes something people depend on.