Evolution of Grammarly's Platform: From Developer Operations to Developer Experience

From Operations to Experience: How Grammarly Rebuilt Its Engineering Culture

 What makes 500 engineers move in sync without slowing each other down? At Grammarly, the answer wasn’t a new framework or another automation layer; it was a change in philosophy. “We stopped thinking about DevOps as maintenance,” said Serhii Vasylenko, Senior Software Engineer at Grammarly. “We started thinking about it as experience design.”

The Moment of Realisation

In 2020, Grammarly faced a familiar growing pain. Teams were shipping more services, deploying faster, and scaling aggressively. But the experience of being a developer inside Grammarly was getting harder, not easier.

Engineers owned their code, their deployments, and their infrastructure. It sounded empowering, until the weight of that ownership started slowing them down. The company had over 500 engineers managing hundreds of backend services across 14,000 nodes, with more than 6,000 CI/CD pipelines running every day.

“It looked impressive on paper,” Serhii said, “but it didn’t feel that way to developers. They were spending more time maintaining the system than building the product.”

The problem wasn’t a lack of talent. It was the absence of a unified platform experience. Something that could balance autonomy with simplicity, scale with sanity.

Building a Platform Like a Product

The turning point came when the platform team reframed its mission. Their goal was no longer to provide infrastructure support; it was to create a developer experience.

Serhii and his colleagues distilled their new approach into a clear ambition: to make developers owners of their services, but remove the friction that came with it. “We wanted engineers to focus on solving customer problems, not infrastructure puzzles,” he said.

The team formalised this shift around four principles: a unified experience, consistent standards, automation-first infrastructure, and technical compliance that maintained reliability across the stack.

“It was a mindset change,” Serhii explained. “We stopped reacting to tickets and started designing like product managers. Our users were engineers, and our product was the platform.”

Laying the Foundations

When Serhii joined Grammarly in late 2020, the developer onboarding process was anything but smooth. “It took me ten meetings to understand what was where,” he said. “It was a maze.”

In 2021, the team began fixing the basics. They launched Platform University, an internal learning system that combined tutorials and tasks to teach developers how to use Grammarly’s tools effectively. They automated provisioning for infrastructure accounts, reducing wait times from days to hours. And they built a living service catalog using Cortex, mapping every service, its owner, and its dependencies.

The impact was immediate. Onboarding time dropped from four weeks to one. New engineers no longer needed a personal guide to find their footing; the system guided them.

“These were small things, but they changed how people felt about the platform,” Serhii said. “It started feeling like a place built for them, not a barrier they had to navigate.”

The Year of Abstraction

By 2022, Grammarly’s engineers could move faster. But the platform team still saw developers losing hours to repetitive setup work. Every new project required configuring CI/CD pipelines, Dockerfiles, logging, alerts, and permissions from scratch.

Serhii’s team decided to abstract that complexity. “We built what we called golden paths,” he explained. “They were pre-built templates for common use cases in Java and Python, complete with all the wiring, code, CI/CD, Docker, and monitoring. Everything.”

Developers could spin up a new service in minutes instead of hours. Terraform automation handled the underlying provisioning, but the interface was a simple web portal.

“It wasn’t about control,” Serhii said. “It was about momentum. The right path should also be the fastest one.”

A Cultural Shift

Technical wins only went so far. In 2023, Serhii’s team realised they needed a cultural shift too. Despite better tooling, different teams were using inconsistent processes. The platform had become efficient but still distant.

The solution was inclusion. The team introduced a shared-responsibility model where developers co-created the tools they used. “We invited them into our process,” Serhii said. “We asked what slowed them down, what frustrated them, and how we could build together.”

That collaboration led to several breakthroughs. A new LLM proxy enabled the integration of internal and external AI models into projects within a single day. An AI-assisted coding environment saved around 200 engineering hours every day. An automated security system used tools like Renovate to identify vulnerabilities and patch them without manual intervention.

The impact wasn’t just technical; it was emotional. “People started seeing platform as a partner, not a gatekeeper,” Serhii reflected. “That was the moment it became a product.”

Scaling the System

Growth came quickly. By 2024, Grammarly’s platform was serving more teams, more services, and more parallel projects than ever before. But with success came a new problem: the platform itself had become a bottleneck.

The solution wasn’t incremental. It was foundational. A small experiment with Kubernetes turned into a complete re-platforming effort. “We realised Kubernetes could make our backend portable, scalable, and more predictable,” Serhii said.

This shift unified configurations across the company. A service mesh simplified communication between systems, autoscaling policies kept performance steady, and cost visibility tools like CloudZero gave the business clarity on cloud spend.

“The biggest surprise,” Serhii added, “was that it helped sales too. Some enterprise clients wanted on-premise versions of Grammarly. Our new architecture made that possible.”

The Human Side of Scale

By 2025, Grammarly’s platform team had grown into three distinct groups: Developer Experience, Release Engineering, and Production Engineering. Each focused on a specific stage of the developer journey. From writing code to deploying to maintaining reliability in production.

But the glue was still experiencing. “We use data to guide everything,” Serhii said. “We track how long it takes to merge pull requests, resolve incidents, and onboard new projects. But the goal isn’t to chase metrics, it’s to keep people in flow.”

The team even introduced small quality-of-life tools. One internal service, Hacker Mango, automatically matched pull requests with the right reviewers. “It seems minor,” Serhii smiled, “but on scale, it saves hours. And it removes friction you didn’t even realise was there.”

The result was a calmer, more predictable engineering environment. One where developers could focus on innovation rather than firefighting.

Lessons for Every Team

Looking back, Serhii believes the success of Grammarly’s transformation wasn’t about Kubernetes, AI, or automation. It was about empathy.

“We co-designed with developers,” he said. “We treated our work like a product. We ran surveys, held workshops, and over-communicated every change. That’s what made the difference.”

For smaller teams, his advice was simple: start small, stay human. “You don’t need a massive team to improve developer experience,” he said. “Just find the biggest pain point between idea and deploy, and fix it end-to-end. Then move to the next one.”

The Next Chapter

Today, Grammarly’s focus is on building a central developer portal. A single place where engineers can see the health of their services, track deployments, and manage costs without ever leaving their flow.

“Infrastructure should fade into the background,” Serhii said. “When developers stay focused on their work, that’s when the real innovation happens.”

The journey from operations to experience transformed not just Grammarly’s tooling, but its culture. “A great developer experience isn’t about pampering engineers,” Serhii concluded. “It’s about giving them back their attention. That’s the most powerful resource any company has.”

Watch the full talk: Evolution of Grammarly's Platform: From Developer Operations to Developer Experience: https://uxdx.com/session/evolution-of-grammarlys-platform-from-developer-operations-to-developer-experience/ 

Or explore all the insights in the UXDX USA 2025 Post Show Report: https://uxdx.com/post-show-report/