At the selection meeting, three people sat across from me, and none of them ever touched the project afterwards. The first delivered the presentation, the second was in charge of "account management", and the third introduced himself as a "solution architect" and said all of three sentences the entire meeting. In the end it was built by a team I only met at the kickoff — a team that knew nothing about half of what had been promised in the meeting. The most important question in a conversation like this appears in no requirements document. It is not whether it can be done. It is: am I talking to the one who sells, or to the one who ultimately builds and runs it?
Anyone who has run IT in a mid-sized company for a while knows the pitch circus. Three vendors, three glossy decks, the same logos of prominent reference clients on slide four all three times. Everyone can do everything, everyone has experience "in exactly your industry", everyone talks about partnership as equals. And in the end the proposals differ in price and tone, but not in the one thing that later decides success or failure — namely, whether the person who makes the promise is also the one who keeps it.
Why References and Tech Stack Are the Wrong First Questions
Looking at the usual things feels safe. References, certificates, the tech stack, team size, years in the market. All of it is in the proposal, can be compared and entered into a scoring matrix. It just rarely measures what actually matters. A reference tells you that at some point someone there built something similar — not that the same people will do it for you. A modern tech stack tells you the tools are right — not that anyone runs them cleanly in production over years. Both are entry tickets, not guarantees.
The more uncomfortable truth is that most of these criteria are met best by exactly those vendors where sales and delivery are furthest apart. A provider with a sales department, a pre-sales team and a pool of interchangeable implementers also has the prettiest reference slides and the most polished presentation. Polish in the meeting and depth in delivery are two different disciplines — and they often do not live under the same roof, sometimes not even in the same company.
Am I talking to the salesperson here, or to the one who builds it in the end?
The Meeting Where the Seam Became Visible
In one selection round where I sat on the buyer's side, the subject was a mid-sized business application — order management, a few interfaces, nothing exotic, around 7,000 transactions a month. Two vendors were in the final round. The first was visibly the larger: a system house with its own sales force, a clean deck, and an account manager who parried every objection with a smile and the phrase "we'll sort that out". In the meeting everything felt smooth. That very smoothness was the warning sign.
We asked the account manager a single technical follow-up question — how the existing, somewhat idiosyncratic interface to the shipping system would be connected, the one that sometimes silently truncates an address field that is too long. He said: "No problem, that's standard for us." When we asked who exactly would implement it and whether we could speak to that person, the answer was: "The team is only decided once the contract is signed." That was the moment the seam between sales and delivery came apart. The man who gave the promise did not even know the answer — he only knew the reassuring formula.
The second vendor was smaller and less polished in the meeting. But the person presenting was also the one who would build it. To the same interface question there was no smooth answer, but an honest one: "I know that truncated address field from two similar projects. This is the point where we have to decide early who corrects the rejected record. If that stays unresolved, it costs us weeks later on." That answer was less pleasant to hear. It was the only one that sounded like real delivery.
The decision went to the smaller vendor, and in hindsight it was the right one. Not because the system house would have been incompetent — but because with them, everything promised in the meeting would have had to pass through two handovers before it reached anyone who actually builds it. Each of those handovers is a point where a promise evaporates without anyone noticing.