Built it with AI and now it is stuck?
An application built with an AI coding assistant or an app-building tool can get a long way and then stall. We read the code, tell you what state it is in and help you decide whether to keep it, rework parts of it or rebuild.
Getting it to work is the hard part
AI coding assistants and app-building tools have let people who know their business well build software for it without waiting for a developer. If you have an application that does a useful job, you have done what many software projects never manage: you worked out what was needed and proved that it helps.
The point at which these applications stall is fairly predictable. An AI tool writes code that satisfies the request in front of it. Unless asked, it usually does not set up the things around the code that allow software to be changed safely for years. As the application grows, each new request disturbs code written for earlier ones, and a change to one screen breaks another.
What these applications commonly lack
- Version control. A record of every change to the code, so that a bad change can be undone.
- A repeatable release. A written or scripted way of putting a new version live, in place of steps that one person carries in their head.
- Backups that have been restored. Copies of the data kept somewhere separate, and at least one occasion on which a copy was restored to prove that it works.
- Tests. Automated checks that the important behaviour still works after a change.
- Proper handling of logins and secrets. Passwords stored safely, each user limited to their own data, and the access keys for other services kept out of the code.
- Protection of personal data. If the application holds details of customers or staff, data protection law applies to it however it was built. Check what is held and who can reach it, and take advice if you are unsure of your obligations.
None of this is peculiar to AI. An application written by one capable person working alone tends to have the same gaps, as our page on systems with no documentation describes. The difference is pace: with AI, the application grows faster than the foundations under it.
Keep, rework or rebuild
There are three possible outcomes, and the choice between them is made after reading the code.
Keep and tidy. The structure is sound. The work is to put the missing foundations in place and remove what is unused.
Rework parts. Most of the application stays. The parts that carry the most risk, often sign-in, permissions and the way data is stored, are rewritten.
Rebuild. The code cannot be changed safely at a sensible cost. The working application then serves as the specification for a new one, which makes the rebuild easier to scope.
We cannot tell which applies to your application until we have read it, and we do not promise that every application can be kept.
How we would start
The first step is a code audit at a fixed price. It takes one to two weeks and produces a written report in plain English, followed by a call to go through it. The report says what state the application is in, what should be dealt with first and which of the three routes we recommend. It is yours whatever you decide.
If you go ahead with us, the next step is one piece of work at a fixed price, with the audit fee credited against it. After that you can take the application back and carry on building, or move it onto a monthly support plan.
We need the source code to do any of this. If the application lives inside an app-building tool, find out whether the tool lets you export the code, and take a copy before anything else. Tell us on the first call which language and tools were used, because our own work is mostly on Microsoft technology.
Talk to us
Describe the system and what you need. You will hear back from someone who can answer technical questions.
Discuss your AI-built application 0800 433 7990What we check first
- Where the code lives
- Whether the full source code is held in version control, a system that records every change, and whether it matches what is running.
- How a change goes live
- Whether a new version is released by a repeatable process, or only from one person's computer or from inside the tool that built it.
- Backups
- What is backed up, where the copies are kept and whether one has ever been restored.
- Logins and secrets
- How users sign in, what each user is able to see, and whether passwords or access keys are written into the code.
- Personal data
- What customer or staff data the application holds, where it is stored and who can reach it.
- Tests and structure
- Whether any automated tests exist, and how much of the code is duplicated or no longer used.
How we take it on
A first call
You tell us what the application does, how it was built and where it has stalled. The first 20 minutes are free.
A fixed-price code audit
We read the code and look at how it is hosted, then give you a written report in plain English with a recommendation: keep and tidy, rework parts or rebuild.
A fixed-price piece of work
The first agreed job, which is usually the foundations and the most serious findings from the audit. The audit fee is credited against it.
A support plan, if you want one
Once the application is on a sound footing, a monthly plan covers faults, updates and changes. You can equally take it back and carry on yourself.
A good fit when
- You or a colleague built an application with an AI coding assistant, and each change now breaks something else.
- A contractor delivered an application built largely with AI tools and has since moved on.
- The application is in daily use and holds customer data, and nobody has checked whether it is secure.
- It works as a demonstration, and you need to know what it would take to put it in front of customers.
Probably not for you if
- You need a formal penetration test or a compliance certificate. Those are specialist services that we do not provide.
- The application exists only inside an app-building tool that will not export its code. Without the code there is nothing to audit, and the practical choices are to stay on that tool or rebuild elsewhere.
- The application is written in a language or framework outside our experience. Our work is mostly on Microsoft technology, and we will say on the first call if another team would serve you better.
Questions we are asked
Can you work with code an AI tool wrote?
Yes. It is ordinary code in an ordinary programming language, and we read it as we would code written by a person. What matters is the language and framework it uses and whether you hold the source code. We confirm both on the first call.
Will you have to start again?
Not necessarily, and nobody can tell before reading the code. Some applications need only the foundations put in place. Some have sound parts worth keeping and others that should be rewritten. Some are quicker to rebuild, with the working application as the specification. The audit report says which applies, with reasons.
Can we keep using AI tools to build on it afterwards?
Yes. The tools are safer to use on a codebase that has version control, tests and a controlled release, because a bad change is caught before it goes live and can be undone. If we are supporting the application, we agree with you who reviews changes before they are released.
Is our application secure?
Nobody can say without looking. The audit checks how users sign in, how secrets are stored, what personal data is held and whether the components the application depends on have known vulnerabilities. It is a review of the code and not a penetration test, which is a separate specialist service.
The person who built it still works here. Can they stay involved?
Yes, and it helps. They know why the application works as it does, which the code does not always show. They can keep building while we look after the foundations, or hand it over fully. That decision is yours.
Tell us about your system
Say what it does, what it is built on and what is worrying you. We will reply with what we would look at first and whether we are the right people to help.