The Future of Technical Presales
I have spent most of my working life in the room where a customer decides whether to spend money. Not the room where the contract gets signed — the one before that, where someone technical from the vendor or partner side has to convince someone technical on the customer side that the proposed thing will actually work. That is presales. On a good day it is solution architecture with a deadline. On a bad day it is reading slides aloud.
For years the job had a comfortable shape. You learned a product line deeply, you built a few demos, you knew the answers to the common objections, and you could respond to a request for proposal faster than the next partner. The value you sold was, in large part, knowledge that the customer did not have and could not easily get. They did not know the licensing edge cases. They did not know which features were vapourware. They did not know how the thing failed at scale. You did, and that asymmetry was the job.
That asymmetry is collapsing. A customer can now open a chat window and get a competent, confident, mostly-correct explanation of any product’s architecture in about fifteen seconds. They can get a feature comparison table, a sizing rule of thumb, and a list of the gotchas — for free, at midnight, without booking a call with a vendor who will try to sell them something. So the obvious, uncomfortable question, the one I think every honest presales person is quietly asking themselves, is this:
If the customer can get the product facts from a machine, what exactly is the human in the room for?
This article is my answer, written from inside the job rather than from a strategy deck. I think the answer is genuinely good news — but only for some of us.
The old model was already rotting
Let me be unkind about my own profession for a moment, because the AI disruption did not arrive at a healthy patient.
A large slice of technical presales had quietly degraded into pattern-matching. There is a recognisable archetype: the person who has memorised the vendor deck, can navigate the partner portal, knows the discount thresholds, and has never actually deployed the product they sell at three in the morning when it breaks. The slideware specialist. The RFP-response factory, where the same boilerplate gets pasted into every proposal with the customer name swapped. The “generic demo” that is identical for a hospital and a hedge fund because nobody bothered to learn the difference. The box-shifter who treats architecture as a bill of materials.
That model worked because information was scarce and the gatekeeping was real. If you wanted to know how a product behaved, you had to ask someone who sold it. The whole edifice rested on the customer knowing less than you.
AI kicks the leg out from under that. Not because the model is smarter than a good architect — it is not — but because it instantly erases the information asymmetry that the weakest presales relied on. The slide-reader sold facts. Facts are now free. The slide-reader is in trouble, and frankly should be.
I do not feel sentimental about this. I have sat across the table from box-shifters as a customer and been actively misled by people who did not understand their own product. The commoditisation of product knowledge is going to be brutal for a particular kind of vendor, and I think the industry will be better for it.
What the machine actually takes
It helps to be precise about what AI commoditises, because the panic and the hype both come from being vague. In my own workflow — and I automate aggressively, the same way I describe in my AI consultancy toolkit — the boundary is surprisingly clean.
AI is very good at the boring sixty percent. The first draft of a proposal. The discovery write-up that turns two hours of messy call notes into a structured summary. Configuration generation — give it the parameters and it will produce a plausible Citrix policy set, a Conditional Access baseline, a Terraform skeleton. Demo scripting. Comparison tables. The “explain this product’s HA model” paragraph. The executive summary nobody enjoys writing. All of that is now a generation away, and pretending otherwise to protect billable hours is both dishonest and a losing bet.
Here is the part the vendors selling “AI for sellers” tools tend to skip. None of that is the actual job. It is the packaging of the job. It always was the low-value layer — the clerical work that surrounded the thinking, exactly as I argued about manual reviews when I built repeatable customer health checks. The clerical work just got cheap. The thinking did not.
What AI does not do — cannot do, structurally, not just “yet”:
It does not hold trust. A customer who is about to bet their reputation on a migration is buying confidence in a person, and that confidence is built over months of being right and, crucially, being honest when you are not sure. A model cannot be on the hook.
It does not exercise judgement under ambiguity. Real architecture is a sequence of trade-offs where the right answer depends on the customer’s risk appetite, their politics, their existing skills, the thing the CFO will not say out loud, and the failed project from two years ago that nobody documented. The model will give you a confident answer to a question you have framed wrong.
It does not ask the awkward question. The single most valuable thing I do in a discovery session is occasionally say “why are you actually doing this?” and watch the room go quiet. AI is relentlessly agreeable. It will help you build the wrong thing beautifully.
It does not own the risk. When the design is wrong, when the cutover fails, when the assumption nobody validated turns out to be load-bearing — someone has to be accountable, and accountability cannot be delegated to a token predictor. The customer knows this even when the vendor pretends otherwise.
And it does not read the room. Presales is a social act. Knowing when to stop talking, when the technical buyer has already decided, when the silent person at the end of the table is the actual decision-maker — that is not in the training data for your specific room.
Old flow, new flow
The shape of the work changes more than the existence of the work. Here is roughly how a presales engagement used to run, and how it runs for me now.
The difference that matters is not “we added AI”. It is that the centre of gravity moves from telling to showing. The demo was always a polite fiction — a curated environment where nothing breaks. The new opening move is to look at the customer’s actual estate and tell them something true about it that they did not know.
This is why I keep arguing that health checks are the new demo. When I can run a tenant assessment or a Citrix posture review and walk in with “here are the three things in your environment that will bite you, ranked,” I have done something no slide and no chatbot can. I have demonstrated competence on their territory instead of asserting it on mine. The demo says “look what this product can do.” The health check says “look what I found in your house.” Only one of those builds trust.
The architect who has actually built things
This is the whole thesis, so let me state it plainly. The dividing line in the next five years of this profession is not AI-literate versus AI-illiterate. It is people who have built things versus people who only describe them.
When product facts were scarce, you could fake depth. You could read the reference architecture, learn the vocabulary, and perform expertise convincingly enough. The customer had no cheap way to call your bluff. Now they do — they can check your claims against a model in real time, and the model knows the documentation better than you ever will. The only thing you can offer that the model cannot is what actually happened when you ran it.
That knowledge does not come from decks. It comes from the lab and from real delivery. It comes from the migration that went sideways at 2am and what you learned rebuilding it. It comes from having run the thing at small scale on your own hardware until you understood its failure modes in your hands, not in a diagram. Half the reason I keep a homelab — the GPU box, the Docker stack, the local LLM work — is that it is the cheapest place in the world to earn the scars that make you credible in front of a customer. I cannot demonstrate judgement I have not paid for.
This connects to something larger I have written about: AI is becoming infrastructure. When a capability becomes infrastructure, the value moves from having it to integrating it well. Electricity is infrastructure; nobody pays a premium for access to it, they pay for the engineer who wires the building safely. Product knowledge is becoming infrastructure in exactly this sense. The premium moves to the person who can integrate it into a working, accountable, context-specific design — and that person is, definitionally, someone who has built working things before.
The consultant as orchestrator
So what does the day actually look like? Less typing, more conductor.
I increasingly treat myself as the orchestrator of a small toolchain rather than the person who produces every artefact by hand. Discovery notes go into a model that structures them. Findings from a health check — pulled by automation, not by clicking through consoles — feed a workflow that drafts the assessment. A proposal skeleton gets generated, then I spend my time on the twenty percent that is actually architecture: the trade-offs, the risks I am willing to put my name against, the things I am deliberately not recommending and why.
A trivial but representative piece of the plumbing — the kind of n8n-triggered draft step I lean on:
# proposal-draft step (n8n http node -> local model)
- node: generate_proposal_draft
model: qwen2.5:14b-instruct-q4_K_M
inputs:
discovery_summary: "{{ $json.structured_notes }}"
findings: "{{ $json.health_check_ranked }}"
constraints: "{{ $json.customer_constraints }}"
instruction: >
Draft sections 1-4 only. Flag every assumption explicitly.
Do not invent figures. Leave risk and commercials blank for the human.
Note the last two lines. The machine drafts; it does not decide. “Leave risk for the human” is not a limitation I am working around — it is the entire division of labour. This is the same discipline that carries an engagement from proposal to production: the AI accelerates the document, but the person owns the commitment, because the person is the one who will be in the room when it ships.
Running the models locally matters here too, and not for ideology. Customer discovery notes, tenant configurations, network diagrams — that is exactly the data you should not be pasting into someone else’s cloud. The homelab inference box is also a confidentiality posture.
The sameness problem, and how you escape it
There is a real risk in all of this, and I do not want to wave it away. If every partner uses the same models to draft the same proposals from the same prompts, every proposal starts to sound the same. AI is a powerful homogenising force. The median output of the profession is about to get blander and more interchangeable, even as it gets faster.
The escape is not a secret prompt. It is genuine engineering depth and a public, verifiable body of work. When two proposals land on a customer’s desk and both are well-written — because both were drafted by competent models — the tiebreaker is whoever can demonstrably show they have done the hard version before. Not claim it. Show it.
This site is my answer to that, and I am being completely literal. The reason I keep a public engineering notebook and treat it as a second brain rather than a private wiki is that it is evidence. When I tell a customer I understand how to run AI workloads on constrained hardware, or how to turn a manual review into a repeatable product, there is a paper trail of me actually doing it, with the mistakes left in. A chatbot can generate a confident claim of expertise. It cannot generate three years of consistent, dated, specific, occasionally-wrong working out. The body of work is the moat, precisely because it is expensive and slow and cannot be faked in a generation.
Where I would put my time
If I were advising someone earlier in this career — or honestly, advising myself — about where to invest as the floor shifts, it would be roughly this, and almost none of it is about prompts.
Build things, for real, on your own kit, until you understand failure modes in your hands. Depth is the only durable differentiator left. Learn enough automation and scripting to be the orchestrator and not the typist — Python and a workflow engine go a long way, which is why I think every infrastructure engineer should learn Python. Get good at the human layer that AI cannot touch: discovery, the awkward question, reading intent, owning a recommendation out loud. And publish. Maintain a body of work that proves the depth is real, because in a world of identical drafts, evidence is the differentiator.
The skill that is depreciating fastest is “I know the product.” The skills appreciating are “I have built the thing” and “you can trust my judgement when it goes wrong.”
What I actually think happens next
I am not worried about AI replacing technical presales. I am quietly optimistic, in the specific way that you are optimistic about a fire that is burning down a building you never liked.
The slide-readers, the box-shifters, the RFP-paste-factories — that work is genuinely going, and it should. The asymmetry it lived on is gone and is not coming back. What survives, and I think thrives, is the architect who has actually built things, who uses AI to delete the clerical sixty percent of the job and spends the reclaimed time on the part that was always the point: understanding a customer’s real problem, making honest trade-offs, and putting their name against a recommendation.
The machine made the facts free. It turns out the facts were never what people were paying for. They were paying for someone in the room who had done it before, would tell them the truth, and would still be there when it broke. That person just got a very powerful set of tools — and a much shorter list of competitors who can do the actual job.