What a First Technical Consulting Meeting Actually Looks Like
Эта статья пока доступна только на английском.
A first technical consulting conversation isn't a sales pitch and isn't a technical deep-dive yet — it's closer to a structured diagnosis.
The actual goal of a first meeting
The first meeting's real job is figuring out whether the stated problem is actually the real problem — a surprising number of technical requests, examined closely, turn out to be solving a symptom rather than the underlying issue.
This is why a good first meeting asks more questions than it answers — "what happens today, exactly, step by step" reveals more than jumping straight to "here's what I'd build."
What a client should actually bring
- A clear description of the current situation, not a pre-decided solution — "we manually reconcile these two spreadsheets every week and it takes hours and produces errors" is more useful than "we need an automation tool."
- Real constraints — budget range, timeline, any non-negotiable technical requirements.
- Who else needs to be involved in the eventual decision, so the consultant knows if this meeting includes the actual decision-maker or is a preliminary step.
What a good consultant should be doing in that meeting
- Asking about the actual workflow in detail, not just the stated problem.
- Pushing back gently on assumptions that don't seem to hold up ("why does it need to update in real time specifically?").
- Being honest if the stated idea isn't actually the best way to solve the underlying problem — even if that means recommending less work, or a different kind of work, than what was originally requested.
A reasonable structure for the meeting itself
| Phase | Focus |
|---|---|
| Understand the current situation | What actually happens today, in detail |
| Identify the real underlying problem | Not just the stated symptom |
| Discuss constraints | Budget, timeline, technical requirements |
| Outline possible approaches | Including the option of no custom build at all, if that's honestly the right call |
| Next steps | What a proposal or more detailed scoping would look like |
Why "we don't need custom software" is a legitimate outcome
A good consulting conversation sometimes concludes that an existing tool (see our custom vs SaaS guide) or a smaller intervention than originally imagined is the actual right answer — a consultant who never reaches this conclusion, regardless of the situation, is optimizing for billable work over your actual interest.
Considering a technical consulting conversation about a real problem you're facing? Get in touch — coming with a clear description of the current situation, not a pre-decided solution, gets the most out of it.
Частые вопросы
Do I need a detailed technical spec before the first meeting?
No — the first meeting's job is often to help figure out what the actual technical approach should be. Coming with a clear problem statement and constraints is more useful than a spec written without technical input.
How long should a first consulting meeting take?
Enough time to genuinely understand the problem, not just enough time to pitch a solution — this varies by complexity, but rushing this step to get to a quote faster usually produces a worse quote, not a faster useful one.
Is a first consulting conversation usually free?
Practices vary — some consultants offer an initial conversation at no cost specifically to assess fit before any commitment, others don't. Worth clarifying this upfront rather than assuming either way.