Build1 publisher2 min readPublished
DoorDash's GenAI platform went API-first after an engineer asked what a notebook was
DoorDash's GenAI Platform team, started around April 2023, chose APIs and SDKs after finding its users were product engineers across the company. Swaroop Chitlur's talk sets out the rules behind it, though the transcript breaks off before any cost or results data.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- Chitlur said he was sweating over the size of the spend when he signed DoorDash's OpenAI contract, a number he now calls minor in hindsight.
- The team took its operating rules from tenets DoorDash already had, including customer obsession, building products instead of systems, and making the right thing easy.
- The team chose to focus on business impact in DoorDash's product and deliberately kept chatbots, and later coding agents, out of its scope.
- Talks with product engineers sorted the company's 2024 demand into three broad buckets: automation, recommendations and personalization.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint Excluding chatbots and coding agents keeps the platform on product features, and leaves internal assistant and coding-agent demand for some other part of DoorDash to serve.
- exposure When best practice lives in platform defaults, one bad default reaches every calling team at once, so the platform team now carries risk that individual teams used to carry.
- capability Chitlur credits fixed principles with carrying the team from models to workflows to agents, so a platform with stated rules can change its product without re-arguing its scope each time.
The first interface choice followed the org chart. Swaroop Chitlur, who started DoorDash's GenAI Platform with a colleague he introduced as Sidd [1], said the group became a team under the ML platform org and was used to talking to machine learning engineers [8]. So in one conversation he told a prospective user to just try an idea in a notebook, and the reply was "what's a notebook?" [9]. The team's first user research turned out to be a glossary check. Chitlur said that exchange moved the team to APIs and SDKs, and away from thinking in notebooks, GPUs or access to compute [10].
I think API-first is the right call for a shared LLM service. The reason is control. A notebook leaves each caller holding the model choice and the credentials. Behind an API, those become platform defaults that one team can change for every caller at once. Chitlur stated the rule behind that design: "If you say, do best practices, nobody's going to do it. You need to bake in best practices into how your platform operates" [7].
Accountability was one of the first questions. Chitlur said that at the time of the contract signing, he was asking: "if this thing takes off, how do we support this in such a large company? How do we make this productive? How do we make this accountable?" [4]. The talk promises "a balance of what was our strategy and what was the technical proof and what was the results" [13]. The transcript excerpt breaks off mid-sentence during the use-case discussion [14], before any technical project appears. It does not show how the team attributed spend to calling teams or measured business impact.
Two conditions decide whether this operating model carries over to another company. The callers have to be engineers building product features, the audience DoorDash found once it asked [10]. The platform also has to own its defaults outright. Chitlur's best-practice rule only works if the platform can change behaviour for every caller [7].
What to watch
- The technical projects and results sections of the full talk, especially any per-team cost attribution or business-impact metric that answers Chitlur's accountability question.
- Whether DoorDash's platform keeps coding agents out of scope now that they exist, since the exclusion was set before any were available.