The research phase nobody bills for
Long before we open a repository on a new project, there is a stretch of unglamorous work: working out what the client actually needs versus what they asked for, what the technical options are, and which of them will still make sense in three years. Historically that work lived in scattered notes, bookmarked documentation and half-remembered conversations.
When reasoning models like ChatGPT reached the point where they could hold a whole problem in context, that phase changed shape for us. It did not replace the thinking — it gave the thinking a sparring partner that never gets tired of the question “but what if the client means the other thing?”
Pressure-testing a brief
The most valuable use is adversarial. We describe a brief to ChatGPT and then spend the session trying to break it: what happens at ten times the data volume, what does this look like for a customer on a phone on a train, which requirement quietly assumes something nobody has confirmed. The model is very good at generating the objections a stakeholder will raise in week six — while they are still cheap to answer.
The second use is comparisons. Platform versus framework, build versus buy, sync versus event-driven — the conversations that used to cost days of reading. We still verify everything against primary sources, because these models can be confidently wrong, but as a way to map the decision space it is the single biggest time-saver in our workflow.
From loose brief to buildable plan
By the end of a research cycle we want three documents: a plain-English problem statement, a shortlist of technical approaches with the trade-offs spelled out, and a list of open questions for the client. ChatGPT has become a natural collaborator for drafts two and three — it is excellent at turning a rambling explanation into a structured comparison table, and at noticing the question we forgot to ask.
The discipline that makes it work is the same discipline that makes any research useful: treat the output as a first draft from a well-read colleague, not an oracle. Everything that reaches a client or a codebase gets read, checked and owned by a human. That was true of search results and it is true here.
What we tell clients
When we explain this to clients, the honest framing is: the tools make us faster at the parts of the job that are about breadth — surveying options, stress-testing assumptions, drafting structure. The judgement about which option is right for your business, and the accountability for that judgement, has not moved. It still sits with us.
That division of labour is the reason our planning phase has stayed thorough even as it has got quicker. The questions are better, the comparisons are wider, and the answer is still ours.
Conversations as an instrument.
Using ChatGPT well in research turns out to be a skill of conversation design. Ask for a decision and you get a plausible answer; ask it to argue the case against your favoured approach and you get the objections you would otherwise meet in month three; ask it to restate a very long brief in its own words and you find out what it, and you, think the brief means.
Sequencing matters too: separate context per question rather than one endless chat, recalibrate after every answer worth keeping, and treat each session as an interview to prepare — like so much of the craft, the quality of the question mostly determines the quality of the session.
The house style problem.
One discipline worth naming: these models write in a voice — smooth, confident, relentlessly balanced — and if research writing goes into client work unedited, everything the studio produces starts sounding like the same confident voice, ours included. So the output enters our documents as raw material, always, and leaves in our own words after our own scrutiny.
The habit protects more than tone. Editing forces the re-reading that catches the errors, mis-weights the emphasis and hunts down the sentence that sounded authoritative and was quietly wrong. Unedited fluency is where these tools cost you, never where they paid you.
Where it is deliberately not used.
The boundaries matter as much as the uses: no client-confidential material into any chat, no personal data anywhere near it, and no decision made on a model's authority alone — the decision-maker is always the person who can be held answerable for the decision.
Those rules predate any specific tool and outlast any model version, which is the point: policies tied to a tool version age badly, and principles tied to accountability age perfectly.
How we would begin again.
If the studio started from zero with these tools tomorrow, the advice would not change: begin in the research phase where errors are cheapest, become fluent there, and keep the codebase out of it until the habit of verification is established.
The trap most teams fall into is reaching for the API before the product has earned its place — this studio did the reverse: research first, code later, and the research earned its keep long before the code did. Learn the product first, the API second — context is the part that compounds.
