Last week, an RFP came in. 47 pages. Client: a DAX corporation. Required: an AI platform for 20,000 users. Deadline for the response: 10 business days.
We declined. Not because the project was uninteresting. But because the process is wrong.
What an RFP Really Says
A Request for Proposal says: We've already understood the problem. We've already sketched the solution. We need someone to implement it. At the best price.
That sounds reasonable. In practice, something different happens.
In our experience, RFPs often describe a solution before the problem is fully understood. The requirements don't always match reality. Not because someone did poor work, but because complex problems are hard to capture in a document.
Why the Process Hurts
RFPs force three things that prevent good projects:
First: Price fixation before understanding. An RFP demands a binding offer before you've understood the problem. So you estimate generously, add buffers, and hope it fits. The result: Either the price is too high and you lose the contract, or it's too low and you deliver under pressure. Both are bad.
Second: Comparability as the goal. RFPs are designed to make vendors comparable. Same questions, same response formats, weighted scoring matrix. This works for commodity services. For an AI project that's never been done before, comparability is an illusion.
What's being compared is the quality of the prose, not the quality of the solution.
Third: No dialogue before the award. In most RFP processes, there's a Q&A round where all bidders can ask the same questions. That's not dialogue. That's formalism. The real questions we would ask are: What have you already tried? Why didn't it work? What does your AWS environment actually look like? You don't ask these questions in an anonymous Q&A round.
What Works Instead
When a company contacts us, here's what happens:
A conversation. 60 minutes. Technical expertise sits at the table, not an account manager. We listen, ask questions, and by the end both sides know whether it's a fit.
If yes, we start in the first week with a login, not a presentation. We look at what exists. Hands-on. And after two weeks, we show a working prototype.
This process worked at Siemens. SiemensGPT wasn't an RFP project. It was a conversation, followed by an architecture sketch, followed by a prototype. After five months, 120,000 users were live.
Same at Siemens Energy. No RFP. The HR department was looking for a specialized partner and engaged us directly. The HR Data Hub became a self-service agent platform, then more projects followed. Not because a procurement process decided it,
but because the results spoke for themselves.
The Other Perspective
I understand why RFPs exist. Large organizations need processes. Compliance requires traceability. Procurement has regulations.
And yes, there are projects where an RFP makes sense: Standardized services with a clearly defined scope. Managed services with clear SLAs. Infrastructure migration following a proven playbook.
But for what we do, it doesn't work. We build things that haven't existed before. SiemensGPT didn't exist before we built it. The HR Data Hub at Siemens Energy didn't exist. The VW Snowpark ML Platform didn't exist. For these types of projects, you can't write an RFP because you can't describe the solution before you've understood the problem.
What This Means for You
We believe the best partnerships don't come from tenders, but from conversations. From 60 minutes where both sides understand whether it's a fit. No slide deck, no NDA before the first word.
If you're looking for a partner who takes accountability instead of billing hours: Let's talk.
We bet on conversations. And we answer every genuine question.
