Roadmaps slip. That is not the story. The story is whether your product dies when they do.

Public reporting around a delayed broader Gemini 3.5 Pro release focused on the right pain points for builders: coding performance and long-horizon reasoning — exactly the jobs agent demos sell. If your stack assumed a single vendor's next model as load-bearing infrastructure, a delay is not a news item. It is a continuity incident.

Solo builders do not get a vendor success manager. They get a written failover table or they get silence.

What a delay actually means

A delayed flagship does not mean the current models stopped working. It means the promised jump is not available on the schedule you may have internalized. Preview access is not production readiness. Enterprise preview is not your free-tier experience. A slide that says a model is nearly ready is not a dependency you can put in a launch checklist.

If your plan was "we will switch to the new one after the release lands," you did not have a plan. You had a hope with a version number.

The failover table (steal this)

Write this before you need it. Keep it next to your model ladder.

Workload Primary Secondary Offline / local Kill switch
Interactive coding agent Workhorse A Workhorse B Local coder if tests exist Disable write tools
Long research synthesis Flagship A Flagship B Local + retrieval notes Cap steps / dollars
Classification / extract Local Fast cloud Local only None needed
Customer-facing copy Workhorse + human edit Alternate workhorse — Human publish gate
Irreversible ops Human + checklist — — No model autonomy

Fill the cells with real model IDs you can call today. Not "whatever is best next month."

How to detect "looks smart, fails multi-step"

Long-horizon failure is sneaky. The model keeps talking. The plan looks coherent. The end state is wrong.

Use a small eval suite you re-run when defaults change:

  1. A coding task that requires three dependent edits and a test.
  2. A research task with a known false lead in the sources.
  3. A tool loop that must stop after N steps even if the goal is unmet.
  4. A "do not invent credentials / paths" adversarial prompt.

Score accepted end state, not eloquence. A model that fails early and admits it is more operable than one that fabricates a green build.

Contingency is a product feature

If you sell reliability, your marketing should not depend on a single lab's launch calendar. If you build in public, your readers should see you survive a slip without drama. Contingency is not pessimism. It is how solo operators look professional while larger teams wait for an email from a partner rep.

The catch: contingency has a cost. Two vendors means two keys, two failure modes, two invoices. That cost is still usually cheaper than a frozen roadmap week when your primary is late and you have no secondary.

What to do this week

  1. List every workflow that assumes "the next Google model."
  2. Assign a secondary that works today.
  3. Run the four-task eval once on primary and secondary.
  4. Put cost ceilings on both.
  5. Delete any launch checklist line that depends on a future version number you do not control yet.

You do not need perfect parity. You need a path that ships while the industry argues about who is late. Write the table once, then keep the model IDs current the same way you rotate API keys: deliberately, with a date, not because a keynote told you to.

Bottom line

Delays are normal. Single points of failure are optional. Write the failover table while you are calm. Use it when the feed gets loud. That is stack maturity — not brand loyalty.