Building GenAI Platform at DoorDash

Interview:

What is your session about, and why is it important for senior software developers?

This session is about the messy middle between a GenAI demo and a production product.

At DoorDash, our experience has been that the model call quickly became the easy part. The hard part was everything around it: model access, routing, tools, identity, evals, observability, cost attribution, governance, and optimization. We'll walk through the bets we made as the landscape shifted from model calls, to workflows and evals, to agents and tools.

This matters for senior software developers because GenAI platform decisions are becoming architecture decisions. Teams need to decide what product teams should own, what should be centralized, when to buy, when to build, and how to move fast without turning the platform into a reliability or governance bottleneck.

Why is it critical for software leaders to focus on this topic right now?

GenAI is moving faster than traditional platform planning cycles.

Two years ago, most platform questions were about model access. Today, product teams need support across agents, tools, identity, memory, evals, observability, cost, and governance. If leaders don't make explicit bets, they either centralize too early and slow teams down, or decentralize too long and accumulate duplicated work, unowned spend, and security risk.

The leadership challenge is not "adopt AI faster." It is to preserve product-team velocity while building horizontal primitives reliable enough for production.

What are the common challenges developers and architects face in this area?

The first challenge is choosing the right abstraction level while vendors, models, protocols, and agent patterns are all changing at once.

The second is supporting experimentation without letting every team rebuild the same primitives: identity, tools, memory, evals, observability, and cost attribution.

The third is deciding which friction is worth keeping. Product teams want zero-friction onboarding, but platforms still need governance, budget ownership, and accountable cost attribution.

The fourth is knowing when a vendor product is good enough to learn from, but not durable enough to become the long-term platform surface.

What's one thing you hope attendees will implement immediately after your talk?

Create a one-page GenAI Platform Bets document: tenets, bets, failure modes, and signals to watch.

For each bet, write down: the target customer, the tenet behind the decision, the trade-off being optimized, the failure mode you are trying to avoid, and the signal that would tell you whether the bet is working or needs to change.

The point is not that every bet will be right. The point is to make your assumptions visible enough that when new pressure shows up, you can adapt without thrashing.

What makes QCon stand out as a conference for senior software professionals?

QCon is one of the few places where the audience wants the tradeoffs, mistakes, and scars, not just the polished architecture diagram.

That is the right audience for this talk. The useful lesson is not "use a gateway" or "use open-weights." It is how senior engineers and leaders make platform bets under uncertainty, keep product teams moving, and evolve the platform when reality changes. The point is not that every bet was right; explicit bets helped us navigate pressure without thrashing.