← Engineering notes

Engineering readiness

Is Your AI-Built App Ready for Customers?

By Essential 4 min read

The useful release question is whether you can show that the application meets the needs of its users. How its code was created is part of the context; the evidence should decide what happens next.

Start with the consequences of failure

List the important user journeys and the consequences of getting them wrong. A booking that disappears, a report that shows another customer's data and a page that loads slowly are different problems. Give each one an owner and a clear acceptance criterion.

Then review the application against the next release, rather than an imagined future with millions of users. Define expected usage, devices, data sensitivity and support needs. This gives the team a proportionate standard and helps avoid spending the budget on features that do not address the immediate risks.

Check complete journeys, not just screens

Run the important tasks from beginning to end in an environment that represents the intended release. Verify what is saved, what another user sees and what happens when someone repeats an action. A button displaying a success message is weak evidence if the underlying operation did not finish.

Include examples that interrupt the normal flow. Try missing inputs, expired sessions, unavailable integrations and a request sent twice. Choose the cases that matter for your product, and record the expected outcome before running the check. Automated tests are useful where they protect recurring business behavior.

  • Does the user receive an accurate result or a useful error?
  • Can the user recover without losing important work?
  • Can repeated actions create unintended duplicate records or charges?
  • Do the important journeys work with a keyboard and on smaller screens?

Verify permissions where data is accessed

Signing in establishes an identity; it does not establish permission to every record. OWASP recommends explicit authorization checks on requests. A review should therefore include whether one user's account can access or change another user's information, even when the interface hides the relevant controls.

Identify secrets, personal information and privileged operations. Review where they are stored and exposed, including logs and error messages. Lovable provides security scans and access-control guidance; use applicable platform tools, then assess findings against the application's actual data and business rules.

Make failure visible and recovery possible

A release needs a way to notice problems after customers arrive. Google's SRE guidance identifies latency, traffic, errors and saturation as useful monitoring signals. For a small product, begin with a manageable set of measurements that show whether the important journeys are working.

Decide who receives an alert and what they should do. Check that a failed deployment can be reversed and that important data can be restored from a backup. A backup configured in a dashboard is less useful than a demonstrated recovery procedure with an understood recovery time.

Confirm ownership, operating cost and handover

Someone should be able to explain which services the application relies on, who controls the accounts and how bills grow with usage. Review usage limits and alerts for hosting, storage, messaging and model calls where those services are present. Do not rely on a prototype's quiet usage to predict a public release.

Ask another engineer to follow the setup instructions. Can they run the project, understand configuration and deploy a reviewed change? Document the maintenance owner, support process and outstanding limitations. These are part of the delivered product, even when they do not appear in the interface.

Turn the review into a release decision

Group findings by consequence and evidence. A data-access failure can block release. A cosmetic improvement can wait. A performance concern may need a representative measurement before anyone proposes architectural work. Each finding should explain the problem, its effect and how the team will verify a fix.

The outcome should be a decision the product owner can use: release within an agreed scope, make specified changes first, or run a focused investigation. Readiness is something a team demonstrates and maintains as the product changes.

Essential reviews AI-built prototypes and implements the engineering work needed for their next stage. Bring the current application and the journeys you want customers to rely on; we can help establish a release plan grounded in the product.

Your next step

Put the thinking into practice.

Discuss your current product, the goal you want to reach and the work needed to get there.

Discuss a production readiness review Book a 30-minute conversation