Pay attention when:
ā¢ You cannot access the source code or the accounts the app depends on.
ā¢ Nobody can explain how the live app is built and deployed.
ā¢ Releases keep slipping, but the plan never gets clearer.
ā¢ Bugs return after being marked fixed, or new work keeps breaking old work.
ā¢ The person doing the work cannot explain what is finished and what is still risky.
ā¢ You are afraid to switch because only one person knows how the app works.
Any one of these can have an explanation. Together, over time, they are a reason to stop and review the arrangement.
Make the issue specific
Ask for the source code, a clear status of the current release, and an explanation of what is blocking progress. Agree on what the next piece of work includes and how you will know it is done.
If the communication improves and work starts moving again, you may not need to switch. If access is withheld, explanations keep changing, or the same failures continue, plan for a handover.
If you do change providers
Secure access to the code, hosting, domain, data, and service accounts first. Ask the incoming developer to understand how the current app works before proposing a rewrite. A short takeover review can show what is safe to keep and what needs attention first.
Look at access, release history, recurring defects, and whether you can understand the next step. Those are better reasons to decide than frustration alone.