My AI-built app keeps breaking. What should I do next?

When a fix causes another problem, start by making the failure reproducible. A useful repair plan connects the reported issue to a cause, a tested change and a controlled release.

You change a form and sign-in stops working. An order appears twice after a retry. A dashboard shows information that disagrees with the database. These are specific behaviors you can investigate in a web app, mobile app or business system.

The tool that produced the code is part of the project history. The repair still needs to start with what the software does today and what you expect it to do.

Write down one failure clearly

Record the steps, expected result and actual result. Include the software version, relevant device or browser and when the problem occurred. If it happens only sometimes, note the conditions you have observed instead of guessing at a cause.

Use test accounts and representative test data when sharing a reproduction. Keep passwords, access tokens and customer information out of screenshots and public issue trackers.

Keep a known version before making another change

Keep the code and configuration needed to identify the current version. Before work that could alter data, check that a suitable recovery copy exists and that the restore procedure has been tested.

Avoid combining an urgent fix with unrelated features. Agree which problem the change addresses so you can tell whether it worked.

Trace the cause across the affected systems

A visible error can involve more than the screen where it appears. Check the request, validation, stored data and any connected service involved in the operation. Compare the reported behavior with logs and a controlled reproduction.

For example, if a request is repeated after a connection failure, investigate how the system identifies an operation it has already processed. The right behavior depends on the workflow. A repeated search and a repeated payment need different handling.

Prove the fix against the original problem

Re-run the original reproduction after the change. Add an automated check where it can reliably detect the failure, and test nearby behavior that the change could affect.

A form repair should include invalid input and an interrupted submission. A change to shared data handling should be checked wherever that same behavior is used. Record the results and any limits on what was tested.

Release in a way you can monitor and recover

Review the change before release and identify who will check the live workflow. Agree the signs that require a rollback or another response. Where data changes are involved, plan recovery for that data as well as the application code.

After release, confirm the affected user journey and watch for the specific failure you set out to fix. Keep the diagnosis and release notes with the project so the next person can follow what changed.

Decide what needs attention next

Some issues have a narrow fix. Others reveal shared behavior that needs a larger change. Use the evidence to separate immediate repairs from planned maintenance, and agree the scope of each.

I can help with repairing or completing an AI-built app, including web applications, mobile apps and their connected systems.

Tell me what is going wrong and what you need the product to do.