How to Build an App with AI: What to Keep Track Of
Building an app with AI is fast and easy. To run it for years, keep the original spec, have the AI maintain docs and version every release from day one.
Overview & context
An AI-built app comes together on its own. How much you get involved in its design, architecture or testing is up to you. Product managers love that to build an app with AI, they just describe in plain words what it should do to a tool like Lovable, Bolt, Cursor or Codex and refine the result with more instructions almost instantly as the AI builds the app. If you work in this agile, iterative way, you need to keep a record of the key information.
1. The simplest way to build an app with AI
AI-built apps come out of two kinds of tools today. App builders like Lovable or Bolt build the whole app in the browser step by step, following the creator's instructions. Once the app is done, they publish it to hosting and set up the database and other services it needs. Coding assistants like Cursor, Codex, Claude Code or GitHub Copilot work directly with the source code in a repository, the folder that holds the code and its change history, so they suit people who can at least read code.
The process is similar in both. You describe what the app should do, the AI creates a first version and you adjust it with more instructions until it works the way you want. You end up with a working app, but the knowledge of how it was built stays in the chat history of that one tool.
2. Why an AI-built app needs a record
AI doesn't remember your project between sessions or across tools the way a developer would. A chat history isn't documentation either: it's long, full of dead ends and stays behind when you move to a different tool. So when you want to add a feature, fix a bug or hand the app over, you'll be digging through the chat to find out which services the app uses and which version last worked.
On top of that, apps today often rely on many different tools and services, so it's hard to keep track of everything an app needs. And with how fast things are changing, you may well start in one tool and continue in another a few months later, carrying the information over.
3. What to keep for every app you build with AI
Keep seven things for every AI-built app. You don't have to write them from scratch: most of them come up while you work, you just need to save them where you and anyone else can find them.
| What | What it's for | Where it goes |
|---|---|---|
| The spec | What the app does and for whom; you check against it that the AI built the right thing. Have the AI maintain a document with the product spec, the architecture, development rules and other details | A shared document (Google Docs, Notion) |
| Prompts and the AI tool project | How the app was built and how to repeat or continue the work. Create documentation for each functional area and describe scenarios and acceptance criteria. | A document with the key prompts and a link to the project in Lovable, Bolt or Codex |
| Services and access | Where the database, hosting, payments and email run, who pays for them and where the keys are managed | A list of services with links to their admin pages; keys in a password manager |
| Versions and changes | What changed when and which version to go back to when something breaks. Fixing one issue can bring back an earlier one. Without a version history you won't notice you're going in circles. | A version history with release notes |
| A test checklist | What to check after every AI change before users see it. Have the AI write its own tests, from basic unit tests to full test scenarios and UI testing. | A document or automated tests in the repository |
| Libraries and their licenses | What the AI added to the app and on what terms you may use it. Set a rule that the AI never adds third-party components without your approval and a license check. | A list of components with licenses |
| Source code | Your own copy of the app outside the tool it was built in | A repository on GitHub or GitLab |
4. API keys and passwords: what stays out of the docs
An API key is a password the app uses to sign in to a service, such as a database or a payment gateway. It doesn't belong in your docs, prompts or source code. Store it in the secret environment variables of the platform the app runs on and keep a copy in a password manager. In the docs, only note which service uses the key and where to enter it.
If the AI put a key into code that runs in the browser, anyone who opens the app can read it. If a secret key ended up in the code, in the repository or in a chat with an AI, generate a new one in the service and revoke the old one.
5. Everything about your app in one place with AboutTheApp
In AboutTheApp, every app has its own page with links grouped into categories. The link to your Lovable, Codex or Claude project goes under AI & Vibecoding and the spec under Analysis & Planning. The repository belongs in Source Code & Architecture, hosting and the database in DevOps & Infrastructure. Links not everyone should see can be marked private: they only show to signed-in team members or with an unlock code.
For each version you record what changed. The Components & Licenses tab lists the libraries the app uses. Versions don't show up on their own: you add them in the dashboard or send them from CI/CD. You can then put an About element with the version and links into the app itself. The Integrate panel on the app card has a ready-made AI prompt your AI assistant can use to add it to your code. AboutTheApp doesn't store passwords or API keys, so for each service, only link to the place where its key is managed.
Frequently asked questions
How do I build an app with AI without coding?
Use a tool that builds the app from a description, such as Lovable or Bolt. You describe what the app should do, refine the result with more instructions and then publish it. For later changes, save the spec, the key prompts, a list of services and a copy of the code in a repository.
What should I save when I build an app with AI?
The spec, key descriptions of how the features work and a link to the project in the AI tool, a list of services with links to their admin pages, versions with a description of changes, a test checklist, a list of libraries with licenses and a copy of the source code in a repository.
Where should I store API keys for an AI-built app?
In the secret environment variables of the platform the app runs on, with a copy in a password manager. A key doesn't belong in code, prompts or docs. If it ended up there, generate a new one in the service.
How do I hand over an AI-built app to a developer?
Give them access to the repository, the spec, a list of services with the account owners, the current version with its change list and the known issues. Share credentials through a password manager, not by email.
Where can I keep all the links for an AI-built app in one place?
In AboutTheApp, each app has a page with links grouped by category: the AI tool project, the spec, the repository, hosting and other services. It also keeps a version history with changes and a list of libraries with licenses. Links that not everyone should see can be marked private.
In short
An app built with AI is an app like any other. Keep its spec, services, versions and tests and you can keep changing it or hand it over without the original chat history.
Want everything about your AI-built app in one place?
Add your app to AboutTheApp for free and attach the AI tool project, the spec, the repository and your services.