Plan — Week 37
Most founders delay their first conversation with a studio because they think they need to arrive with a spec. A feature list. Some sense of the architecture. Enough technical detail that they won't sound naive on the call.
That instinct is backwards, and it's worth saying plainly: if you already knew the technical shape of the solution, you wouldn't need discovery. You'd need a quote.
Two ways to get this wrong
The first failure mode is arriving with too little. "We want AI to help with customer service" or "we think there's an opportunity in our onboarding" is a direction, not a brief. It can't be scoped, because nobody can tell yet whether the problem is a five-day build or a five-month one. Everyone ends up guessing, and guesses in a fixed-price conversation tend to guess high, because the studio is pricing the risk of the unknown, not the actual work.
The second failure mode is arriving with too much — specifically, a document that has already decided on the solution. A chatbot. An n8n workflow. A particular model. This usually happens because someone read a case study or watched a demo and worked backwards from the tool to the problem. The trouble is that the right architecture almost always depends on details that only surface once someone maps the actual workflow — what system holds the data, how clean it is, where a human needs to stay in the loop for judgement or compliance reasons, what happens on the exception path. Specify the solution too early and you can lock in the wrong one before anyone has tested the assumption.
The useful middle ground is a brief that describes the problem in enough operational detail that a studio can ask good questions, without pre-deciding the answer.
What actually goes into a good brief
A few things, none of which require technical knowledge:
The problem in operational terms. What's broken, who's affected, and how often. Not "our sales process is inefficient" but "leads sit in a shared inbox for two days before anyone qualifies them, and by the time we call, half have gone quiet." Specificity here isn't about impressing anyone — it's what lets a studio tell whether this is a genuine bottleneck or a symptom of something upstream.
The systems currently in the mix. Which tools touch this process — your CRM, a spreadsheet someone maintains by hand, an inbox, a booking system. You don't need to know how they'd be integrated. You just need to name them.
Who owns the decision and who does the work. These are often different people, and it matters. The person who feels the pain daily (a coordinator drowning in manual data entry) and the person who signs off on spend (the ops director) frequently have different priorities, and a discovery conversation goes better when both are represented, or at least accounted for.
What "working" looks like. Describe the outcome, not the interface. "Leads get a response within the hour, and someone only gets pulled in when the enquiry needs judgement" is a usable target. "We want a smart assistant" is not.
A budget range and a timeline appetite. Even a rough range — "somewhere in the tens of thousands, and we'd want something live this quarter" — helps a studio scope realistically instead of everyone circling the number for the first twenty minutes of the call.
Constraints that would rule things out. Compliance requirements, an existing vendor relationship you're locked into, data that legally can't leave the country. These narrow the solution space early, which saves everyone time.
What you genuinely don't need
You don't need a feature list. You don't need to have chosen a model or a vendor. You don't need a fully accurate process map — a rough one is fine, and discovery often reveals it wasn't quite accurate anyway, which is useful information rather than an embarrassment. You don't need a business case with ROI projected to the decimal. Directionally right is enough to start a conversation; precision comes later, once there's something concrete to measure against.
How this turns into a fixed price
A discovery conversation exists to turn an operational brief into a technical shape: what needs to be built versus configured from existing tools, which systems need integration and how deep that integration has to go, where the work genuinely needs AI judgement and where a simple deterministic rule will do the job more cheaply and reliably.
This is also why the price range for this class of project is wide. The visible complexity of a feature — "can it read documents and answer questions" — tells you very little about the actual cost. A tidy-looking chatbot sitting on top of five disconnected, messily formatted data sources can cost more to build properly than a workflow that looks complicated on a whiteboard but sits on one clean, well-structured system. The integration and data quality work is usually where the hours go, not the part that ends up on the screen.
Where the friction actually shows up
Parts of the brief will turn out to be wrong, and that's not a failure of preparation — it's what discovery is for. It's fairly common for the conversation to reveal that the thing you wanted automated isn't the actual bottleneck; something further upstream is quietly causing the pain you're trying to solve downstream. A good discovery process should be willing to say that, even if it means recommending a smaller or different project than the one you walked in with.
Fixed price also requires enough investigation up front to be a responsible number, not an optimistic one. If a studio quotes a fixed price from a fifteen-minute call, be a little sceptical — that number is either padded to cover the unknowns, or it's a guess that will turn into change requests later. A short, explicitly scoped discovery phase before the fixed-price quote is a reasonable thing to expect, and it protects both sides from being bound to a number that was never grounded in the actual work.
And once a fixed price is agreed, scope discipline matters in both directions. A studio should hold the line on what was quoted rather than letting the build quietly expand. You, in turn, should expect that anything genuinely new that surfaces mid-build — not a refinement of what was scoped, but a new requirement — gets a conversation and a change order, not a shrug and an absorbed cost. Neither side benefits from pretending fixed price means unlimited.
The practical takeaway
You don't need to arrive at a discovery call sounding like an engineer. You need to arrive able to describe the problem clearly, who it affects, what it currently costs you in time or money, and roughly what you'd be willing to spend to fix it. The rest — the architecture, the tooling, the technical trade-offs — is the studio's job to work through with you, not yours to solve before you pick up the phone.
If you're sitting on a problem you can describe but haven't been able to scope, start a conversation. Bring the problem, not the solution.
