Your AI-built app is “90% done”. What should you check next?

In a demo, a user creates an account, selects a product and clicks Pay. The screens are present, so the remaining work appears small. A completion percentage without a list of verified workflows gives a product owner little control. The most visible features may be ready while the rules that keep the business operating remain unresolved.

Choose one complete journey, from the customer’s first action to the outcome the company is responsible for. For an illustrative digital-goods service, that means selecting an item, confirming payment, obtaining it from a supplier, delivering it and finding the order later. Every transition needs a clear basis.

Ask for a demonstration using a fresh account and write down the conditions for success. Record any manual interventions: editing a database record, running a command again or sending an item by hand. These may be acceptable during a pilot when their limits and an owner are agreed in advance.

Problems often emerge where two individually working components meet. Payment succeeds but the supplier is unavailable. A customer refreshes the page after clicking a button. A staff member cancels an order while payment confirmation arrives. Each case needs a defined outcome that someone can explain to the customer.

Create a small table with four columns: action, starting state, possible failure and expected result. A repeated request should not silently create another purchase. If the outcome is uncertain, staff should know what to check and the customer should receive an accurate status.

The Primax case connects payment, transaction checks, a supplier and code delivery. It illustrates a useful acceptance boundary: a successful payment is one step, after which delivery still needs to complete correctly. This describes the product’s workflow, without making claims about measured operational results.

Walk through important actions under different roles: customer, staff member and administrator. Can a customer view another order by changing a link? Does a disabled employee retain access? Can a price be changed in a request even when the field is hidden on screen? A specialist should perform these checks in an agreed test environment.

For technical security verification, OWASP ASVS provides an open requirements framework for web-application security controls. It helps define the review’s scope. Having a checklist or a report is not, by itself, a security guarantee.

The business still needs to specify data ownership, permitted roles and the consequences of inappropriate access. A developer should not have to guess whether someone from another department may read a client’s documents. Exports, deletion and access removal when an employee leaves also need explicit decisions.

Ask someone to deploy the application in a separate environment using its instructions. Check which external accounts and credentials it depends on, who owns them and what happens if a provider is unavailable. A transferable product should not depend on the original builder’s laptop remaining open.

Then test recovery using a non-production copy. Did the necessary data return? Are links between orders and payments intact? Can staff follow the procedure? A backup file and a successful restoration are different deliverables. Products with offline support need another decision: how changes made before reconnection are reconciled.

In Plivex, offline use and later synchronisation belong to the user journey. It is a useful illustration of why readiness depends on how data behaves under changing conditions, rather than how many screens have been assembled.

A useful review separates launch blockers, acceptable pilot limitations and improvements that can wait. Each finding should include a reproducible example, its consequence and a way to verify the fix. “The code needs improvement” does not give an owner enough information to choose a next step.

A rebuild needs a concrete justification: incompatible data states, an inability to enforce agreed access rules or an unsustainable cost of change. Sometimes a focused repair and another test are enough. Using AI during development is not, on its own, a reason to discard the project.

The accompanying Russian-language video discusses the trap of judging readiness by visible progress. Start with one critical workflow and its release conditions. Bring those to a technical review discussion, so the conversation concerns the product’s actual risks and practical ways forward.