Writing
Is your AI-generated codebase ready for a real customer?
Many of the founders I talk to now built their first product with AI coding tools, sometimes without an engineer on the team. That is a good way to find out whether anyone wants the thing. It is also how a company arrives at its first paying customer with a codebase nobody has fully read. Nothing about that is shameful, but a few things change the day money changes hands, and they are worth checking before the customer finds them.
What changes
Before a customer, a bug costs you an afternoon. After a customer, a bug costs you the customer, and a security mistake costs you the next ten. The code itself does not need to be beautiful. It needs to be owned, tested where it matters, recoverable when it breaks, and locked where it should be.
The six things to check
Ownership. Do you control the repository, the cloud account, the domain and every third-party service the product depends on, in accounts in your company’s name? Founders are regularly surprised to find a critical account under a contractor’s personal email.
Tests. Not coverage numbers; the question is whether the two or three flows that make money (signing up, paying, doing the core thing) have automated tests that run before a change ships. AI tools will write those tests if asked, and it is the first thing I ask for.
Secrets. API keys, database passwords and tokens should live in a secrets manager or environment configuration, never in the code. AI-generated projects are unusually prone to hard-coded keys because the tool was optimizing for “works now.”
Backups. Taken is not the same as restored. Restore the database to a fresh environment once, time it, and write down the steps.
Access. Who can log in to production, and is it more people than it should be? Turn on multi-factor authentication for everything that supports it.
Deploys. Can a change go from a laptop to production in a repeatable way, and can it be rolled back? If deploying means someone copying files by hand, that is the next thing to fix.
What is fine to leave alone
Inconsistent naming, duplicated code, a framework choice you would not make again, an architecture that will not scale to a million users. None of that matters at your first ten customers, and rewriting it now is the most common way early companies waste six months. Leave it, note it, and fix it when it is actually in the way.
When you need an engineer rather than a tool
The tools are good at producing code and poor at judgment: what to build, what to leave out, what is risky, what the customer will actually notice. When the questions you are asking are about judgment rather than output, when the same bug keeps coming back in different clothes, or when a customer’s security team sends a questionnaire, you have reached the point where a person who has done this before is cheaper than the alternative. That person does not have to be full-time, and they do not have to be me, but they have to have read the code.