Who can use it
Vibe coded
Anyone with the link, often with admin rights
Viable product
Real accounts, roles, and permissions
Prototype to product
We can all vibe code now. Building it right still takes experience.
AI has made it much easier to build software. It is just as easy to miss API limits, get user access rights wrong, or make architectural decisions that work perfectly for 100 users and fall apart at 10,000. James builds fast, knows where AI falls over, and puts the foundations in from the start.
“Speed isn't the goal. It's a setting.”
Dr James Cannan
Vibe coded vs viable
What changes between a demo and a product
AI and API costs
Vibe coded
No caps. One user or one bot can run up the bill
Viable product
Rate limits, usage limits per user, spend alerts
Secrets
Vibe coded
API keys in the browser or the repo
Viable product
Keys server side, rotated, and scoped
Your data
Vibe coded
Open database rules, no backups
Viable product
Locked down rules, backups, audit trails
Inputs
Vibe coded
Trusts whatever is typed in, prompts included
Viable product
Validation and prompt injection guards
Growth
Vibe coded
Works for 100 users, falls apart at 10,000
Viable product
Architecture planned for the next order of magnitude
When it breaks
Vibe coded
You find out from a customer
Viable product
Monitoring, error tracking, and alerts
Next developer
Vibe coded
Inherits a tangle and wants to rewrite it
Viable product
Clean repo, tests, docs, and AI tooling set up
Common problems
What usually breaks after the demo.
These are the failures James has seen across years of production launches. Each one is cheap to prevent at the start and painful to fix after real users arrive.
01
Runaway AI bills
An endpoint with no rate limit gets scripted overnight. The invoice arrives before anyone notices.
02
Exposed keys
A key shipped to the browser is found and used. Rotating it breaks the product for everyone.
03
Open data
Default database rules let one user read another user's records. In health or finance, that is a reportable breach.
04
Manipulated prompts
Users talk your AI feature into ignoring its instructions, leaking data, or doing something you never intended.
05
The rewrite tax
Payments, logins, and personal data skipped in the rush. The first serious developer you hire spends months rebuilding instead of moving forward.
06
Investor diligence
A technical review finds no tests, no access control, and no plan. The round slows down or the valuation drops.
How James works
Build fast and build right…
- 1
Prototype with intent
Fast, AI-assisted builds that test the riskiest assumption first. Knowing what to build, when to build it, and where AI will fall over.
- 2
Harden the foundations
Authentication, roles, API and usage limits, secrets, database rules, validation, logging, and backups. The boring parts that protect the company.
- 3
Hand over cleanly
A repo developers want to work in: tests, CI checks, documentation, and the right AI coding tools configured, so every new hire starts on the right foot.
- 4
Stay as your advisor
Senior technical advice for the decisions that follow: hiring, vendors, architecture, and what not to build next.
Two-minute check
Is your prototype ready for real users?
Ten honest questions. Get a score, see your gaps, and email yourself a short report. Takes about two minutes.
FAQ
Before you book
Can you take over a Lovable, Replit, Bolt, or Cursor prototype?
Yes. That is a common starting point. We keep what users validated and rebuild the parts that will not survive real traffic: authentication, data model, security, limits, and tests.
Do I have to throw my prototype away?
Usually not. A review shows what can stay, what needs hardening, and what should be rebuilt. You get that in plain language before any build starts.
Why not just keep vibe coding?
Keep using it to explore. It is a great way to learn what users want. The risk is shipping it to paying users, health data, or investors without the limits and security a real product needs.
Who owns the code?
You do, from day one. It lives in your repositories and your accounts.
Have a prototype? Talk it through.
Bring your prototype, or just the idea. In 30 minutes you will know what can stay, what has to change, and what it takes to get to real users.