IndustriesWorkPlaybookHow it worksAboutBook a systems auditBring us your idea

Playbook  /  When to call someone

How to brief someone on a system an AI half-built

Straight answer

Brief someone by telling the honest story: what you set out to build, what the app does now, what is broken, and what you cannot answer. Show them the app, the code and where your data lives, then say plainly what you want. A candid brief saves everyone money, because guesswork is what makes quotes balloon.

Information current as at 5 July 2026

A good brief is the cheapest thing you can give a potential partner, because it turns guessing into pricing. When you built with AI, you may feel you cannot brief anyone because you do not fully understand what you made. That is fine. An honest account of what you do and do not know is exactly the brief a good partner wants.

Plain English
Brief
A clear account of what you built, what you want, and what you already know.
Repository
The stored home of your code, usually on a service like GitHub.
Read-only access
Permission to look at something without the ability to change it.
Scope
The agreed boundary of what a piece of work will and will not cover.

Step by step

  1. Tell the honest origin storyStart with what you set out to build and who it is for, in a few plain sentences. Say which tool you used, roughly how far you got, and whether real people are using it yet. This context shapes everything a partner will assess. Do not dress it up or apologise for it: "I built a booking tool for my clinic in Lovable, it takes bookings but the reminders are broken" tells a good partner more than a page of polished description. The origin story frames what kind of help you actually need.
  2. List what works, what is broken, and what you are unsure ofWrite three short lists. What currently works and you rely on. What is visibly broken or missing. And, most valuably, what you simply cannot answer: whether your data is safe, whether keys are exposed, where things are hosted. That third list is not an admission of failure; it is the map of the unknowns a partner needs to price honestly. Guesswork about unknowns is exactly what makes quotes balloon or fall apart later, so naming them up front protects your budget.
  3. Gather the access, but share it safelyCollect the practical facts: which builder or platform, the code repository if you have one, where the database lives, what services it connects to. You do not need to hand over full control to get a quote; read-only access or a screen-share walkthrough is often enough at the assessment stage. Never paste live passwords or secret keys into an email or a chat. A trustworthy partner will ask for access through proper, revocable channels and will not need your raw secrets to tell you what work is involved.
  4. State the goal, not the solutionSay what you want to be true at the end, in outcomes: "I want it secure enough to take payments", "I want to own it so I am not locked in", "I want the reminders working and the whole thing stable". Resist prescribing the technical fix, because you may be wrong about the cause, and a good partner's value is partly in diagnosing it. Naming the outcome rather than the method lets them tell you the real path, which may be simpler or different from what you assumed.
  5. Ask them to reflect it back before any work startsFinish by asking the partner to summarise, in their own words, what they think you have and what you want. This one step catches misunderstandings while they are still free to fix. If their summary matches your reality and adds useful detail, that is a strong sign. If it glosses over your unknowns or leaps straight to a big rebuild without engaging your actual goal, that is a signal worth heeding before any money changes hands.
No pressure
Show us what you built.

If you have made something and it needs to become real, send it over. We will tell you honestly what it needs to be live, safe and yours, whether that is a quick fix you can do or a proper build. No obligation.

Common questions

Questions, answered

What if I do not understand my own app well enough to brief anyone?
That is normal with AI-built systems and it is not a barrier. Your honest account of what you do not know is the brief. A good partner expects gaps and treats mapping them as part of the job. Describe what you see and admit what you cannot, and that is enough to start.
How much access should I give just to get a quote?
At the quoting stage, read-only access or a guided walkthrough is usually plenty. You are asking someone to assess, not yet to build, so they rarely need full control. Never share live secret keys or passwords in plain text. Grant access through proper channels you can revoke once the conversation ends.
Should I tell them my budget?
A rough range helps more than it hurts, because it lets a good partner shape a realistic plan rather than guess. It does not mean spending all of it. If a partner uses your number only to price up to it without justifying the work, that is a warning sign. Honest ones use it to tell you what is and is not possible.
What if different people quote wildly different things?
That usually means your brief left too much open, so each read it differently, or that some are quoting a full rebuild while others quote a targeted fix. Tightening the brief and asking each to explain their reasoning narrows the gap. Wildly different quotes are often a sign to ask better questions, not just to pick the cheapest.
Keep reading
What should I have ready before I call someone? →Questions to ask before paying anyone to fix your app →What does a good first conversation with a studio look like? →your-idea →All playbook articles →
No pressure
Show us what you built.

If you have made something and it needs to become real, send it over. We will tell you honestly what it needs to be live, safe and yours, whether that is a quick fix you can do or a proper build. No obligation.

Start here

Two doors. Same senior team.

Whether you can name exactly what you want built, or you just know something is leaking, the next step is the same conversation.