data.day

I Will Not ‘Trust the Roadmap’: Procurement Is Not Faith

A vendor's roadmap is a marketing document, not a legal one. Why we refuse to sign contracts based on features that exist only in a PowerPoint.

The Fiction of “Q4 Delivery”

The Vice President of Product flew in from the West Coast. He was charming, articulate, and showing us a slide deck that promised a utopia of data interoperability.

“I see you require an Open API for bulk export,” he said, clicking to a slide showing a beautiful, complex diagram. “That is our top priority. We are shipping it in Q4.”

“That is excellent,” I replied, keeping my hands folded. “Then we will resume this negotiation in Q4.”

His smile faltered. “Well, we can sign now to lock in the pricing, and you’ll be first in line for the beta.”

“Mr. Vice President,” I said, “You are asking the Municipality to dismantle its existing infrastructure and move its Citizens into your territory, based on a promise you are legally free to break. That is not procurement. That is faith. And the state is secular.”

The Dependency: The Roadmap as a Pacifier

The “Roadmap” is a tool designed to maintain dependency during periods of inadequacy. When a vendor lacks a critical feature—specifically features related to sovereignty like data portability or encryption keys—they use the roadmap to delay the client’s exit.

They treat the roadmap as currency. They expect us to trade our current, tangible requirements for their future, theoretical code.

But a roadmap is:

  1. Non-Binding: Read the fine print. “Forward-looking statements are subject to change.”
  2. Market-Driven: If a bigger customer demands a different feature next month, your export button will vanish.
  3. A Trap: Once we sign, we lose leverage. Why would they rush to build the exit door after we have already locked ourselves inside?

[Image of a bridge that stops halfway across a chasm, labeled “Q4 Roadmap”]

The Sovereign Choice: The “Code-on-Contract” Rule

We have established a rigid protocol for these discussions. We call it “Code-on-Contract.”

If a feature is essential for the legal or operational safety of the Citizen (e.g., GDPR compliance, bulk export, offline capability), it must be demonstrable in the production environment before the signature ink dries.

If the vendor insists the feature is “imminent,” we offer them a Conditional Clause:

“The Municipality shall withhold 40% of the annual license fee until Feature X is delivered and verified by our technical team. If Feature X is not delivered by [Date], the contract is void and the vendor shall refund all implementation costs.”

Suddenly, the “imminent” feature turns out to be “complex.” The timeline shifts from Q4 to “next fiscal year.” The truth is revealed.

We do not trust the roadmap because we cannot govern with “coming soon.” The Citizen needs water, electricity, and rights today. Not in Q4.

FAQs

What if the feature really is coming next month?

Then we will sign the contract next month. We do not pay for groceries that are still in the field.

Can't we put the roadmap in the contract?

We can try, but vendors will fight to keep it vague. Even if we succeed, a breach of contract lawsuit is slower than a Citizen needing help.

Does this make us look inflexible?

It makes us look serious. A sovereign entity does not gamble with its digital borders.