How to choose who reviews and keeps building your AI-built app

You built the app with AI, it works, and it already has users. But you have no technical team, and the moment has come to put someone senior on the code.

JP Systems is the software engineering team for founders who don't have a technical team, so this is a conversation we see often. And we see the same pattern: people choose on price or on rapport, and only later find out what they should have asked.

These are the questions we would ask. Including of ourselves.

First, what you actually need

"Someone to work on the app" can mean four different things, and not every studio does all four:

• Review: look at the code and the database and say what is at risk.
• Fix: resolve what the review found.
• Keep building: add features without breaking what exists.
• Maintain: be there when something fails or needs updating.

Know which of these you want before you ask for quotes. It changes the questions, and it changes the price.

The seven questions

1. Who will actually touch the code? Ask to speak to the person doing the work, not only the person selling it. Ask what experience they have with apps in production, with real users, not just prototypes. An AI-built app needs someone who understands what the AI generated and what it left undone.

2. What happens when something breaks on a Friday night? Who picks up, through which channel, and how fast. If the answer is vague, what you are buying is a project, not a partner.

3. Who owns the code, and where does it live? The repository should sit in an account you own, and so should the hosting and database accounts. If the code only exists on the vendor's systems, you are their hostage the day the relationship ends.

4. How will you know it's moving? Ask for phased deliveries, with something visible in the first weeks. Months of silence followed by a single hand-over is the scenario where problems only surface at the end.

5. How is it paid for, and what happens if the scope changes? Fixed price per phase, hourly or retainer: any of the three can make sense, as long as it's clear what is included and how a change is handled. Be wary of a fixed price quoted by someone who hasn't seen the app.

6. What do they do with your users' data? Anyone working on a live app can reach personal data. There must be a data processing agreement in place before any access (Article 28 GDPR), and you need to know who has access, where the data lives and when access is withdrawn at the end.

7. How do they stop the problem coming back? Fixing a flaw is not enough if the next AI-generated change reopens it. Ask about automated tests and a pipeline that runs them. Without that, you pay for the work twice.

Red flags

• They promise to rewrite everything without having seen the code. In most cases we see, it isn't needed, as we explain in rewrite or stabilise.
• They ask for production access without a data processing agreement.
• The code stays in their account.
• They can't explain what they will do in language you understand.
• They say the AI handles everything and senior review isn't needed.

How we work

We start with a free 30-minute diagnostic, to understand what you have in production and what worries you. Then we audit the code, the architecture and the database, with findings ranked by severity and backed by evidence, before touching a line. The fix is phased: the critical items first, without stopping the business and without rewriting from scratch when that isn't needed. We leave tests and CI in place so that what is fixed doesn't break again. Payment is phased too, and we only move on when you're satisfied.

In one real case, that path closed 16 cross-company data leaks in an AI-built app.

If you want to see the full process, it is on our page about auditing and fixing AI-built apps.

Have an AI-built app and want a second opinion? Take the 2-minute diagnostic or book a 30-minute conversation.