Short answer
Six shifts, and the common thread is moving the hard questions earlier. We open discovery by asking what the client has already tried with ChatGPT or a no-code wrapper and what happened; we address AI capability mismatches as a deliberate agenda item in the first session instead of when they surface; we walk through a formal no-go list of AI features that are not viable in production; we separate "AI inside a product" from "a thin wrapper on an AI API" because those are very different projects; we raise the data conversation in the first scoping session rather than in technical design; and we tell clients upfront that AI work starts with a paid discovery that becomes the basis for the build quote.
A year ago, scoping calls for software projects occasionally touched on automation. Today, almost every scoping call for a new client includes a conversation about AI. ChatGPT made that happen. GPT-4 made it more specific. Here are the six ways our discovery process has shifted as a result.
1. We Now Ask What They Have Already Tried
Before ChatGPT, clients describing an automation problem had typically not attempted to solve it themselves. Now, a significant portion arrive having already tried a ChatGPT-based solution - either using it directly, or using a no-code AI wrapper. Their experience with that attempt is the most useful input we can get.
If it worked, we understand the problem is solvable and we know the rough shape of the solution. If it did not work, we learn where the edge cases are - what the model got wrong, where the output was inconsistent, what the client ended up doing manually anyway. That failure report is worth more to scoping than a fresh brief.
We now open discovery with: "Have you tried to solve this with any tools already? What happened?"
2. The Capabilities Conversation Has to Happen Earlier
Clients who have been using ChatGPT for personal productivity arrive with intuitions about AI capabilities that are partly right and partly not. They know it can write, summarize, classify, and converse. They sometimes believe it can do things it reliably cannot: consistently return perfectly structured data, access real-time information without a retrieval layer, remember prior conversations across sessions without an architecture that enables it.
We used to address capability mismatches as they surfaced. Now we address them in the first session as a deliberate agenda item. Not to deflate expectations, but to ground them in what production systems actually require as distinct from what a consumer chat interface does.
3. We Have a No-Go List for AI Features
Some features that seem like natural AI candidates are not viable for production because of reliability, latency, cost, or regulatory concerns. We have formalized a short no-go list that we walk through when AI is on the table.
Items on the list: features that require consistent structured output without a validation layer, autonomous actions with financial or legal consequences and no human review step, any feature in a regulated context where the model output could be mistaken for professional advice, and real-time requirements in latency-sensitive environments where model response time would be a user experience problem.
We did not have a formal no-go list before ChatGPT. The volume of AI-adjacent briefs made one necessary.
4. We Separate "AI Inside" From "AI Wrapper"
Clients often arrive asking for an "AI product." We have found it useful to clarify early whether they want AI as an internal processing layer inside a product with its own interface and workflow, or whether they want a thin interface on top of an existing AI API with their own prompting.
These are very different projects. The first is a full product build where AI is one component. The second is lighter-weight but requires careful prompt engineering and output handling to be reliable. Confusing them leads to misaligned expectations about timeline and cost.
5. Data Conversation Is Earlier in the Process
AI features that work well in demos often fail in production because of data. The training data, the input data format, the edge cases in real user language, the missing values in structured records. We now raise the data conversation in the first scoping session rather than in the technical design phase.
Questions we ask: where is the data coming from, what format is it in, who is responsible for its quality, and what happens when the input is malformed or incomplete? These questions have changed more than a few scopes.
6. We Quote Discovery Separately for AI Work
For non-AI projects, we often have enough information after one or two scoping calls to issue a quote. For AI-adjacent work, we almost always need a brief technical discovery phase first. The number of unknowns - data quality, model selection, output validation, integration points - is too high to price accurately from a brief.
We now tell clients upfront: AI work starts with a paid discovery. The discovery output is the basis for the build quote. This is not new as a practice, but making it explicit as an expectation for AI work specifically has reduced scope friction significantly.
If you are thinking about an AI integration and want to talk through what the scoping process looks like, we are happy to start there.
Questions · 05
Frequently asked questions
What is on your no-go list for AI features?
Features that require consistent structured output without a validation layer, autonomous actions with financial or legal consequences and no human review step, any feature in a regulated context where the model output could be mistaken for professional advice, and real-time requirements in latency-sensitive environments where model response time would be a user experience problem. We did not have a formal list before ChatGPT; the volume of AI-adjacent briefs made one necessary.
Why does AI work need a paid discovery when other projects do not?
For non-AI projects we often have enough information after one or two scoping calls to issue a quote. For AI-adjacent work the unknowns - data quality, model selection, output validation, integration points - are too many to price accurately from a brief. The discovery output becomes the basis for the build quote, and making that expectation explicit upfront has reduced scope friction significantly.
We already tried solving this with ChatGPT and it did not work. Is that useful?
That failure report is worth more to scoping than a fresh brief. It shows us where the edge cases are - what the model got wrong, where the output was inconsistent, and what you ended up doing manually anyway. If your attempt did work, that is useful too: we know the problem is solvable and we know the rough shape of the solution.
What is the difference between "AI inside" and an "AI wrapper"?
"AI inside" means AI is an internal processing layer within a product that has its own interface and workflow, which is a full product build where AI is one component. A wrapper is a thin interface on top of an existing AI API with your own prompting - lighter-weight, but it needs careful prompt engineering and output handling to be reliable. Confusing the two leads to misaligned expectations about timeline and cost.
What data questions should we be ready for?
Where the data is coming from, what format it is in, who is responsible for its quality, and what happens when the input is malformed or incomplete. AI features that work well in demos often fail in production because of data - the input format, the edge cases in real user language, the missing values in structured records. Those questions have changed more than a few scopes.
