From Day 1 to Production: Building Lyft’s Analytics & Rides Intelligence Assistant as Onboarding Project
Written by Sagar Baronia at Lyft.
A Different Kind of Day One
Most onboarding journeys follow a familiar arc: orientation sessions, benefits enrollment, setting up your laptop, and gradually finding your footing over the first few weeks. Mine followed that arc too, but with an additional thread running alongside it from the very start.
I joined Lyft in March 2026 as a Senior Data Scientist — Algorithm on the Marketing, Business & Ads team, bringing close to a decade of experience in data science, first at Oracle and then four years at Amazon. From the very first conversation with my manager, Ravi Chandra Babu Ginjipalli, it was clear that my onboarding would have an extra dimension. Alongside the standard new hire track, I would take on a real production project: one designed to teach me Lyft’s systems by shipping something through them.
The project: build the production frontend, from scratch, for Lyft’s Analytics & Rides Intelligence Assistant — ARIA for short. This is the story of going from Day 1 to a live production service in three weeks.
Aria: From Prototype to Production
Aria is an AI-powered tool that lets Lyft employees explore ride analytics data through natural language. Instead of writing SQL queries or navigating dashboards, approved employees at Lyft can ask questions like, “How many rides were there in SF last month?” and get answers instantly.
The backend intelligence already existed. My team had built the service that powers Aria’s AI agent: the LangGraph orchestration, the SQL generation pipeline, the semantic layer, all of it. But the user-facing layer was running on Streamlit — functional for prototyping, but not production-grade. It was fine for the handful of us in the team testing it, but it couldn’t scale to the whole company, didn’t plug into Lyft auth, and lived outside the standard service framework. That meant Aria couldn’t graduate from prototype to something the rest of Lyft could actually use.
The goal was to build a proper web client using our internal Node.js framework and Next.js, connected to that existing backend, with real authentication, real deployment infrastructure, and a real path to scale. Today, Aria is actively used by approved employees across Lyft, with adoption growing week over week.
The Onboarding Philosophy: Learn by Shipping
Ravi’s reasoning for this project-centric approach was deliberate. At a senior level, the challenge of joining a new company isn’t learning a language or a framework — it’s understanding how the organization’s specific production ecosystem fits together. How does authentication work here? What does the deployment pipeline look like end to end? How are services discovered, routed, and monitored? A frontend project that needs to go to production forces you through all of these questions in a matter of weeks, because you simply cannot ship without answering them.
This was not about skipping the standard onboarding. Every Friday, I had dedicated hours for the regular new hire track: the compliance courses, the orientation sessions, the checklist items that every new Lyfter completes. The project ran in parallel, not as a replacement, and the two tracks reinforced each other. The onboarding material made more sense because I had real context for it, and the project moved faster because the onboarding filled in gaps I would have otherwise had to ask about.
My onboarding buddy, Alex Gao, a fellow Full Stack Applied Scientist on the team, was instrumental in those early days — helping me orient to the codebase, the team’s processes, and the company’s rhythm.
The Support System That Made It Possible
An ambitious onboarding project only works if the culture supports it. From my first week, Alex introduced me to the Slack channels that would become my daily references: the networking channel for all Envoy and DNS questions (critical when you’re configuring a production frontend), and the frontend engineering channels where software engineers, product designers, and frontend specialists shared patterns and solutions.
I was also introduced to staff software engineers across teams who were remarkably responsive when I hit walls that documentation alone couldn’t resolve. Glen Cheney, a Staff Software Engineer on the frontend platform team, was particularly helpful when I was working on getting the streaming connection between the frontend and backend to work properly. Rather than having me debug from scratch, Glen pointed me to an existing internal service that had already solved a similar streaming pattern. I dug into that service’s repo, traced how it handled the streaming handshake and kept the connection alive, and adapted the pieces that mapped to our setup. What could have been days of trial and error turned into an afternoon of focused reading and a working prototype by the end of the day.
That kind of guidance, where an experienced engineer helps you find the right reference instead of reinventing the wheel, is what makes the difference between a good onboarding and a great one.
This cross-team generosity wasn’t an exception. It reflected a culture where helping someone outside your immediate team is a natural part of how engineering operates at Lyft.
Week 1: Standing Up the Foundation
The first task was creating the Aria frontend repository and generating the Lyft Node Service scaffold. I configured all the necessary plugins — authentication, logging, metrics, service client — and built the initial layout shell for the chat interface.
Then came the infrastructure work: Envoy static configuration for routing, DNS setup with CNAME records and CloudFront aliases, and staging deployment. The first real lesson came quickly. An early deployment issue led me to diagnose an authentication plugin incompatibility, which I resolved by switching to a different plugin that was better suited to our setup. The deployment stabilized, and by the end of the week, Aria’s staging environment was live. It wasn’t doing much yet, but the scaffold was standing, and I had already learned more about Lyft’s deployment infrastructure than weeks of reading could have taught me.
Alongside the project, my first week at Lyft had its own rhythm. I went through NYC orientation, met other new hires, and started settling into the company’s culture. There were the practical logistics that come with any new job: getting payroll and benefits in order, completing verification paperwork, setting up equity accounts and commuter benefits. I also spent time configuring my development environment, getting familiar with AI-powered coding tools, and raising my first test PR just to learn how the review and merge flow works at Lyft. It was a full week in every sense.
Week 2: Making Systems Talk
With the frontend deployed to staging, the focus shifted to connecting it to the backend. I built the connectivity layer to the Aria backend service and began iterating on manifest file changes and deployment configurations to get the two services communicating properly.
This turned out to be less straightforward than expected. The connection kept running into issues, and the usual debugging approach of reading logs locally wasn’t enough. This is where Grafana became an invaluable tool. By tracing requests through Grafana’s log aggregation, I was able to identify that the root cause was in the Envoy setup — the session configuration wasn’t wired correctly, which was silently breaking the connection between services. Fixing it was relatively quick once the problem was visible; the real learning was building the instinct to reach for Grafana first when something feels off — tracing a request across services, scanning logs by time window, narrowing down which hop in the chain is actually broken. It’s a habit I rely on almost daily now.
This week’s other significant piece was building the XState state machine for chat state management. Chat interactions involve a surprising amount of state: session IDs, message sequences, streaming progress, error handling, connection lifecycle. XState gave us a structured way to model all the possible transitions and keep the UI predictable even when the network wasn’t.
On the onboarding side, I was still working through the remaining items from the new hire checklist and picking up the tools and processes that make day-to-day work at Lyft smoother. I also got my first taste of Lyft Pass — a small but fun perk that comes with being here.
Week 3: The Last Mile
With the backend connectivity solid, the final week’s focus was on getting Server-Sent Events (SSE) streaming working end to end. This is the piece that would make Aria’s chat interface feel responsive and modern, with answers streaming in token by token rather than arriving as a single block of text.
There was a minor hiccup in how the streaming needed to be configured on the frontend side. The way the SSE connection was being piped through the Next.js API route required a specific setup that wasn’t immediately obvious from the documentation. With help from the frontend platform team, we got the streaming pipeline working smoothly. In the process, we also discovered that the token chunk size coming from the backend was too large, which made the streaming feel choppy rather than fluid. This required a change on the backend side to send smaller, more frequent chunks: a good example of how frontend work often surfaces issues that live elsewhere in the stack.
The week also included production hardening: DNS management changes for CNAME and CloudFront alias in production, Envoy static config updates for production virtual hosting, and adding test cases to increase coverage across the repository. By the end of the week, Aria was live in production.
By this point, I had wrapped up the mandatory training that should be done by week three, keeping myself on track with onboarding courses and checklist items. I also spent time exploring what future iterations of the frontend could look like, having early discussions with Product Design and gathering feedback from the team on what they’d want to see next.
The Aria frontend — live
What This Taught Me About Lyft
There is a line often attributed to physicist Richard Feynman: “What I cannot create, I do not understand.” The principle applies not just to physics but to any complex system. You can read every architecture document, study every infrastructure guide, and attend every onboarding session, but still not truly understand how a production system breathes until you have pushed something through it yourself. The auth plugin that wouldn’t cooperate, the Envoy session config quietly breaking the connection, the streaming chunks that were just a bit too big — none of that was in any onboarding deck. You only learn it by hitting it.
Three things stood out to me about Lyft’s engineering culture during this process.
The internal tooling is mature. Lyft Node Service, Envoy, metaservice, InfraDocs — these are not aspirational frameworks. They are well-maintained, well-documented systems that a new engineer can genuinely build on top of from week one. The “getting started” guides actually get you started.
Cross-team support is authentic. Staff engineers from other teams answered my questions, reviewed context, and helped me debug issues that were outside their immediate scope. It reflected a culture where helping someone outside your immediate team is a natural part of how engineering operates at Lyft.
The documentation culture is real. The High-Level Design document that guided this project, the frontend platform docs, the infrastructure references — they were genuine working documents that I used daily, not artifacts gathering dust in a wiki.
What’s Next for Aria
The frontend is just the beginning. The roadmap ahead includes data visualization with charts for richer analytical responses, enhanced chat history management, archived chat retrieval, and custom rendering components for specialized data displays. Each of these builds on the infrastructure that is now in place: the deployment pipeline, the state management patterns, the streaming architecture.
Aria is already helping Lyft employees get answers to data questions faster than ever. The next phase is about making those answers richer and more actionable.
Closing Thought
The best way to understand a production system is to ship something through it. Three weeks, one new service, and a much deeper understanding of Lyft’s engineering ecosystem than any course alone could have provided. I’m grateful to Ravi for designing an onboarding that trusted me with real impact from day one, to Alex for being an exceptional onboarding buddy, to Glen for pointing me to the right references when I was stuck, and to every engineer across Lyft who answered a Slack message from the new person who had yet another question about Envoy configuration.
When onboarding gives someone a real challenge, points them at the right channels, and trusts both the technical and human systems to support them, the result isn’t just a shipped project — it’s a new hire who actually understands how the company works.
From Day 1 to Production: Building Lyft’s Analytics & Rides Intelligence Assistant as Onboarding… was originally published in Lyft Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.
