Vibe coding
How to brief a developer to take over your AI-built project (with a one-page template)
AI Cubed
September 9, 2026
7 min
Handing an AI-built project to a developer goes badly for a predictable reason: the developer doesn't know what they're looking at, and the founder doesn't know what to say. The result is either a vague quote or a week of discovery billed at build rates. A one-page brief fixes most of it.
Copy the template below, fill it in, and send it with access. It's the same information we ask for before an audit, so it works for us and for anyone else you talk to.
The one-page brief (template)
Copy this and fill in every line. If a line doesn't apply, write 'n/a' rather than deleting it — the absence is information too.
- What it does — two sentences. Who uses it and what they do with it. ('A scheduling app for mobile dog groomers. Groomers set availability; customers book and pay.')
- How it was built — the tool(s) (Lovable, Cursor, Bolt, Replit, v0, other), roughly how long, and whether anyone else has worked on it.
- Where it runs today — the URL, the hosting (the tool's, Vercel, Replit Deployments…), the database (Supabase, Firebase, Replit DB…), the auth provider, the payment provider.
- What's broken — the exact error text or a screenshot for each item, and what you were doing when it happened. Number them.
- What 'done' means — one sentence a stranger could verify. ('Fifty real customers can book and pay on my domain, on their phones, by the 30th.')
- Users and stakes — how many real users now, any revenue, any investor or launch date, any regulated data (health, finance, children).
- Timeline and budget shape — the real deadline, and whether you want a fixed quote, a phased plan, or hourly (say fixed).
- What you'll give access to, and what you own — repo (read access), test login, database (read), hosting. And whose name each account is in today.
What to send with it
| Item | How | Why |
|---|---|---|
| Repository | Read access on GitHub, or a zip | Everything starts here |
| Running app + test login | URL, a test account that isn't your admin | Lets them see the real behaviour |
| Database | Read access, or a schema export | Data model and policies are half the audit |
| Hosting / deployment | Viewer access, or a note on where it runs | Deploy config is where many apps are stuck |
| The brief | One page, as above | So they don't bill you to discover it |
Don't send admin credentials or production secrets in the first message. Read access is enough for an audit, and anyone who says otherwise is telling you something.
Four questions to ask them back
- Who will do the work, and are they the person I'm talking to?
- Will you give me a written list of what's broken and what it'll cost to fix, before I commit to the fix? (An audit, in other words.)
- Whose name will every account be in when you're done?
- What would make you tell me to rebuild instead of fix — and would you tell me?
The answers you want: 'me'; 'yes, fixed price, two or three days'; 'yours'; and a specific answer that mentions the core flow never having worked, or the architecture, not 'we'd never say that'.
What AI Cubed does about this
Send us the brief and read access and you'll get a two-business-day audit: every finding in plain English, a fix-or-rebuild call, and a fixed quote. See vibe-coding rescue or MVP to production.
Frequently asked questions
Related
Start here
See where your operation is losing time.
Twenty minutes with an operator, not a salesperson. We'll name the one bottleneck costing you the most — and tell you whether it's worth fixing with software at all.
Book your free 20-minute consult→20 minutes · video call · no preparation needed