You built it with AI. Now what?

If you built or rebuilt your business software with an AI tool and it works, the next step is not more building. It's making it safe to run the business on: a repeatable way to deploy, tests that run on every change, a staging environment, tested backups, and a named person with a response time who answers when it breaks. None of that is hard. Almost none of it comes out of the tool.

Why this is suddenly a common situation

A year ago, an owner without an engineering background couldn't rebuild a production platform. Now they can. We've watched a non-technical founder take a legacy application through several years of framework upgrades, rebuild the admin side, deploy it to a hosting provider, and test it against staging data, working alone with Claude Code over a few months. Nobody on the team knew until it was mostly done.

That's real. It's also the beginning of a new problem — and the owner who does it usually knows. The words we hear are "I don't know what I don't know" and "I'm running my business on this and I'm nervous."

Both are the right instinct.

What the tool doesn't give you

AI coding tools are very good at producing working software. They are not set up to give you the things that make software safe to depend on. In our experience, the gaps are consistent.

A deployment pipeline. The tool can run the deploy command for you. It can't give you a consistent, repeatable path from "code written" to "live for customers" that works the same way when you're on vacation. That's a pipeline, and it needs to be built once, on purpose.

Test coverage that keeps up. You can prompt for tests. Most people don't, and the ones who do stop once things work. Tests that run automatically on every change, so the software checks itself before you see it, are what let you keep building without fear.

Staging before production. A place where changes land first, with real-looking data, before customers see them. If your only environments are "my laptop" and "live," every change is a small gamble.

Data safety. Backups that have actually been restored. Secrets that aren't in the code. Access in the business's name, not in yours or a tool's.

Someone who can look. An engineer who reviews what the tool produced before it goes live. Not because the tool is wrong, but because the button that appeared in the admin panel yesterday might be doing more than you asked.

What "done" means for software a business runs on

Here's the checklist we'd want true before we'd tell any owner to stop worrying:

1. The code lives in a repository the business controls, and it matches what's running.
2. There is a staging environment, and every change lands there first.
3. Deploys run through one pipeline, the same way every time.
4. Automated tests run on every change, and someone knows where the gaps are.
5. Backups run on a schedule and have been restored at least once.
6. Every account is in the business's name.
7. Someone has committed to a response time, in writing.

If you can check all seven, keep building. The tool made you fast; the list keeps you safe. If you can't, the missing items are the work, and they're smaller than the build you already did.

How to keep building without becoming the bottleneck

The owner who built it is now the only person who understands it. That's the same single point of failure as the freelancer who left, with a different name on it.

The way out is not to stop building. It's to put what you build into a process where someone else can see it: changes described as tickets, each one landing on a preview you can review, an engineer signing off before production, and the deployment handled the same way every time. You keep the direction. The process keeps the software safe. And the next person who needs to understand it has something to read.

That's what we mean by run and grow. You built it. We stay after launch.

Where to start

If you want a pass or fail on what you built, the Owner's Manual is a week and six plain-language documents, signed off by an engineer. If you already know the gaps and want them closed, an Adoption Sprint gets your software into a pipeline with first fixes live in production by day 14. Both are on the Run & Grow page. Or talk it through first.