You opened an AI coding tool on Friday night. By Sunday you had a working app: sign-up, a dashboard, maybe a payment button. It feels like the hard part is over, and for a demo it is.
A demo and a product are different things. A demo only has to work when you use it. A product has to keep working when strangers use it, mistype things, attack it, forget their passwords, and trust it with their data and their money.
In short: AI coding tools are very good at making things work and much less careful about making them safe, reliable, and affordable to run. Hardening is the pass that closes that gap. For a solo founder it takes days, not months, if you fix things in the right order.
Why Vibe-Coded Apps Need Hardening
The model that wrote your app was optimizing for one thing: your next prompt succeeding. "It runs and the feature works" is the finish line. It doesn't know who your users are, what data you hold, what an attacker would try, or what a mistake would cost you. Nobody told it, and you probably didn't think to ask.
The result is a familiar set of gaps. They aren't exotic. They are the ordinary mistakes of fast, unreviewed code:
- API keys and passwords written straight into the code, and pushed to a repository.
- Checks that happen in the browser but not on the server, so anyone can skip them.
- Pages that show user A's data to user B once someone edits a number in the URL.
- A database left open to the internet, or with default access rules.
- No backups, or backups that nobody has ever restored.
- No limits, so one bot, or one loop in your own code, can run up a large bill.
- Packages added without a second look. AI assistants sometimes suggest libraries that don't exist, and attackers can register those names.
- No tests, no monitoring, and no way to roll back a bad change.
Why It Matters More When You're Solo
In a company, someone else usually catches these things: a security team, a reviewer, an on-call engineer. When you are building alone, you are the security team, the ops team, and the on-call rotation. There is no second pair of eyes unless you arrange one.
The stakes are also personal. Your product is your reputation. One leaked customer list, one wrongly charged card, or one weekend of downtime with nobody watching can end the trust you spent months earning. Once you hold other people's personal data, privacy law such as GDPR and CCPA also starts to apply to you, however small you are.
The Hardening Checklist
You don't need to do everything at once. The sections below are roughly in order of how much damage each problem can cause.
1. Secrets and configuration
Search the whole repository, including its history, for keys, tokens, and passwords. Move them into environment variables or your host's secret store, make sure .env files are ignored by git, and rotate anything that was ever committed. Deleting a key from the latest version doesn't remove it from history.
2. Authentication and access control
Don't write your own login. Use a proven provider or your platform's built-in auth. Then check the part AI tools miss most often: authorization. On the server, for every request, confirm that this user is allowed to see or change this specific record. If you use a backend-as-a-service with row-level rules, test them while logged out and while logged in as a different user.
3. Input, data, and uploads
Validate everything on the server, not just in the form. Use parameterized queries, escape user content before showing it to other users, and treat file uploads with suspicion: limit type and size, and never serve them from a place where they can run as code.
4. Database and backups
Keep production data separate from development. Give the app the minimum database permissions it needs. Turn on automated backups, then restore one into a test environment. A backup you have never restored is only a hope.
5. Payments and webhooks
Let a payment provider host the card form so card numbers never touch your servers. Verify the signature on every payment webhook, and make your handlers safe to run twice, because providers retry. Otherwise, someone can fake a "payment succeeded" message, or a retry can grant access twice.
6. Abuse and cost controls
Add rate limits to sign-up, login, password reset, and any endpoint that costs you money. Set hard spending caps and alerts on your cloud account and on every paid API. If your product calls an AI model, a missing per-user limit is a direct hole in your margins. This is the same economics I wrote about in Token Pricing Economics, from the other side of the table.
7. If your product uses AI agents or LLM features
Anything an attacker can get into the model's context, such as a web page, an email, or a support ticket, can try to give it instructions. Give agents the fewest tools and permissions they need. Require human approval before irreversible actions like sending money, deleting data, or emailing customers. Treat model output as untrusted input, log what the agent does, and cap what each user can spend.
8. Dependencies
Commit your lock file. Run your package manager's audit command and turn on automated dependency alerts. Before you install a package an AI suggested, check that it exists, that it is the real project, and that people actually use it. Remove packages you don't need.
9. Monitoring and recovery
Install error tracking and an uptime check, so you learn about an outage from an alert and not from a customer email. Keep logs, but keep passwords, tokens, and personal data out of them. Have a staging environment and a way to roll back the last deploy in minutes.
10. Tests for the money path
You don't need full coverage. Write a few automated tests for the flows where a failure costs real money or trust: sign-up, login, checkout, access to paid features, and data export or deletion. They also give you the confidence to keep changing the app with AI help without breaking what works.
11. The legal basics
Publish a privacy policy and terms of service, honor deletion requests, and be clear about which cookies and analytics you use. This is not legal advice, so have a lawyer look it over once you have paying customers, but don't launch without the basics.
If You Only Have One Weekend
- Remove and rotate exposed secrets.
- Add server-side access checks and test them with two different accounts.
- Turn on backups and restore one.
- Set spending caps and rate limits.
- Add error tracking and an uptime alert.
These five remove most of the risk that can end a young product. The rest of the checklist can follow over the next weeks.
Using AI to Help Harden
The same tools that created the gaps can help close them. Ask your coding assistant to review the code specifically for security problems, to list every endpoint and the access check it enforces, or to write tests for the paths above. Free scanners also help: secret scanners such as gitleaks, your package manager's audit, static analysis such as Semgrep, and the OWASP ZAP scanner for a running app.
Use them as a first pass, not a final verdict. A model reviewing its own code tends to share its own blind spots, and scanners can't tell whether your business logic is right. The people most likely to find what's left are an experienced person with a fresh pair of eyes, or an attacker.
How I Can Help
I'm Ariel Tunik, a fractional CTO. Many of the founders I talk to are strong on product and customers, and they want to turn what they built into something they can charge for without learning security and operations on the job. Here's how I work with them:
- Hardening review. I go through your app, repository, and cloud setup, and hand you a prioritized list of what to fix: severity, effort, and the order I'd tackle it in. You can fix it yourself, with your AI tools, or with my help.
- Hands-on fixes. For the items you'd rather not do alone, such as access control, secrets cleanup, backups, deployment, and monitoring, I can do the work alongside you.
- AI feature and agent hardening. If your product runs LLM features or agents, I review permissions, prompt-injection exposure, cost controls, and evals.
- Ongoing technical leadership. When you're ready to grow, I can stay on as your part-time CTO: architecture decisions, hiring your first engineers, and keeping the product reliable as it scales.
Moving fast with AI is a real advantage, and I'm not suggesting you give it up. Hardening is the step that lets you keep that speed once other people depend on what you built.
Frequently Asked Questions
Is a vibe-coded app safe to launch?
It can be, but not as generated. AI-built apps usually work on the happy path and skip the protective layers: secrets handling, per-user access checks, backups, rate limits, and monitoring. A focused hardening pass on those areas is what makes it safe enough to put real customers and their data on it.
What should I fix first in an AI-built app?
Start with the failures that are hardest to undo: exposed secrets and API keys, missing server-side access checks, untested backups, and uncapped spend on AI or cloud services. Then add monitoring so you hear about problems before your customers do.
Do I need a full security audit before launching?
Usually not at the start. A solo product needs a prioritized review of the highest-risk areas, with fixes ordered by impact and effort. A formal audit or penetration test makes sense later, when you handle sensitive data, sell to larger companies, or need a compliance certificate.
Get in touch to talk about your app, or send me the link and tell me what worries you most.