If you want to understand how Bolt’s products evolve, you need to look at where engineering and product work come together. Berlin is one of the hubs where core features are built, tested, and scaled long before they reach customers.

Teams here work on product and platform systems used by more than 200 million people worldwide, tackling challenges from experimentation at scale to complex mobile, backend, and data systems.

With a strong presence of Product roles, the Berlin hub is defined by close cross-functional collaboration and end-to-end ownership — from early RFCs through experimentation to global rollout.

Below, three engineers from our Berlin team show what that looks like in practice.

RiderX: experiments in the margins, impact at scale

For Nami Salimi, Engineering Manager in RiderX, the appeal is the mix of speed and scale: “There’s a thrill in making something from nothing, seeing it come to life quickly and be used by millions.”

RiderX owns the rider journey from booking to pickup to drop-off. On paper, most major players offer similar features, so the real differentiation happens in the details. Nami explains: “The biggest challenge is big and obvious ideas have mostly been tried and tested, so we look for nuanced, market‑specific improvements, and that’s where most of the fun is.”

The way those ideas become reality is what stands out to Nami.

Having joined Bolt only a few months ago, he noticed how work is structured in RiderX:

"Engineers are involved well beyond implementation — contributing to problem definition, experiment design, and decision-making together with product managers."

With the proper preparation, experiments move quickly — from a thought to a live test in days, and to a measurable impact in weeks. In practice, that speed stems from breaking down ideas early. Features are defined in RFCs, scoped to the smallest viable experiment, and often launched in a limited set of markets before being rolled out more widely. App changes, analytics, and success criteria are separated upfront, allowing teams to validate assumptions quickly without committing to global complexity too early.

At the same time, Bolt’s scale demands discipline. When Nami joined, he found more than two dozen initiatives running in parallel. His job was to turn that into focused progress: “As an engineering manager, your biggest impact is cutting through noise, focusing on what matters, and unblocking work that crosses team boundaries.”

RiderX conducts multiple experiments every week, particularly around rider cancellations at various stages of the trip. Each experiment only moves metrics slightly, but cumulative gains add up to a meaningful impact on both experience and business.

Platform: data that lets teams move fast, not guess louder

If RiderX is the visible surface, Platform is one of the engines behind Bolt’s data‑driven culture.

Felix Wöll, Senior Software Engineer on the Data Platform, works on systems that product teams across Bolt rely on for reporting, experimentation, and decision-making at scale.

The Platform team is distributed across Berlin, Warsaw, Bucharest, and Tallinn. No single hub owns everything; instead, engineers collaborate across offices to build and maintain core data components that product teams worldwide rely on.

A recent project Felix worked on was deceptively simple: ensuring key management reports are ready before 6:00 every morning, rather than sometime between 9:00 and 12:00. In practice, it meant optimising pipelines, tightening dependencies, and aligning ownership across teams. The outcome was faster, more reliable reporting for leadership.

Behind that sits a deliberate focus on safe speed. Felix explains: “For rollouts, we rely on standard CI/CD practices and built‑in safeguards. Every change undergoes automated testing and validation before being deployed. It’s not flashy — just a steady, reliable setup that lets us move without unnecessary risk.”

Data quality is treated as infrastructure. Automated freshness checks, clear ownership, and reproducible pipelines enable analysts and engineers to focus on insights instead of firefighting.

Pipelines are built with explicit ownership and freshness guarantees, so downstream teams know when data can be trusted. In the case of leadership reporting, this meant tightening dependencies and validating pipelines end-to-end to ensure data availability before 6:00 every morning, turning a previously variable process into a predictable one.

For Felix, this kind of work connects to Bolt’s broader goal of making cities more livable. "Cities are made for people, not for cars," he says. "Reliable data systems may not be visible to users, but they enable teams to make better decisions about how products behave in real cities.”

AI is part of that workflow in a pragmatic way. The team utilises tools like GitHub Copilot or Cursor, along with instruction files that the AI coding agent uses to understand how repositories fit together. Additionally, the team leverages integrations into Jira, Confluence, and Slack to automatically surface relevant context. It’s not a replacement for engineering judgment, but a productivity layer on top of it.

Felix puts it pragmatically: "The work stays interesting because the systems keep evolving, but there’s enough structure and ownership that improvements actually stick instead of being constantly reworked."

Over time, these practices make the platform more predictable and easier to build on. Clear ownership, explicit data guarantees, and conservative rollout mechanisms enable teams to enhance reliability without compromising delivery, allowing incremental improvements to compound into a long-term impact.

Mobility: from Berlin hackathon to global feature

Evgenii Sukhanov's path demonstrates the far-reaching impact of work done in Germany.

He joined Bolt in Tallinn 4 years ago as a Senior iOS Engineer, motivated by the chance to work on a product used by millions. What stood out was the significant room engineers have to shape the process, product, and technical direction. After growing into a team lead role and relocating to Berlin, his scope expanded.

Today, as a Staff Software Engineer in Mobility, he works across iOS, Android, backend, analytics, testing frameworks, backend‑driven UI, and performance — leading features end‑to‑end. "The role combines deep technical work with responsibility for architectural decisions and rollout strategy across multiple teams and platforms," he says.

That end-to-end ownership is not theoretical; it often starts small and scales fast. One such example began at a Berlin hackathon. The project, “Find Me a New Driver”, was designed for situations where the first matched driver is too far away. What began as a hackathon prototype has evolved into a global feature, used by over two million people every month, and has reduced client cancellations by 1.18%.

Another cross-team initiative he led was the project mentioned in Nami Salimi’s interview, targeting areas with poor pickup spots where drivers can’t stop or wait. To solve this, Bolt created a Pickup Experience workgroup across driver, rider, and geo teams. On the driver side, they added a way to report problematic pickup points and now collect around 650,000 reports each month. On the rider side, they redesigned the pickup flow to guide users to better locations and warn them in “no‑waiting” areas, reducing waiting time and cancellations for both sides.

This is typical of Staff-level work: connecting problem framing, cross-team execution, and measurable outcomes.

"I start by understanding the actual user problem and what would count as success. From there, I try to keep decisions aligned, both with the user experience and with how the system's long-term health."

Quality and reliability are non-negotiable at this scale. Mobility teams ship weekly, so confidence in every release matters. Features are covered with unit, snapshot, and UI tests; responsiveness is designed in from the start so riders and drivers see trip updates in real time; and every change is hidden behind a feature flag, tested internally in almost 50 countries, then rolled out through closely monitored A/B experiments — all while maintaining a 99.99% crash-free session rate.

That attention to quality extends beyond what users can see. In one case, a refactor in a core funnel unintentionally removed key analytics events. The UI looked fine, but important data had gone missing. To prevent this kind of silent failure in the future, the team expanded UI tests to validate analytics alongside user behaviour, ensuring that product decisions are always based on reliable data, not assumptions.

Cross-functional work in practice

Across engineering, teams tend to spend time clarifying the problem before deciding what to build.

Nami describes it this way: a developer might propose a new cross‑sell idea when supply is low. As an Engineering Manager, his role is to help shape that idea. For example, by exploring whether they can start with a smaller, simpler version in a few markets first, learn from it, and then scale with confidence.

Evgenii outlines the documentation backbone that enables this collaboration: product RFCs to define the problem, technical design documents for mobile and backend, shared API RFCs on GitHub, and an A/B experiment scorecard that captures assumptions and results. The goal is less about formality and more about preserving context so teams can build on each other’s work.

Much of this comes from working closely with product teams. Engineers are involved in defining metrics, shaping experiments, and making architectural trade-offs – not just "build what's in the ticket".

Berlin life: global work, local rituals

Being based outside Bolt's Tallinn HQ means a slightly different setup — smaller teams and a more distributed day-to-day - while working on the same global products.

As Nami puts it, "Any product announcement is the result of the whole team. No one checks which office you sit in."

Berlin adds its own character. For Nami, the city’s history was a strong pull — passing places where major events of the last century took place is a daily reminder of how fast things can change.

Inside the office, small rituals help keep weeks sustainable. His mostly Berlin‑based team holds regular coffee breaks where one person brings something to eat, the team sits, talks, and maybe plays a game. Taking thirty minutes away from work helps make it feel like more than just a job.

Who thrives at Bolt in Germany

Seen together, the work coming out of Berlin reflects a familiar pattern in teams building at scale: problems are clearly defined and scoped early, changes ship incrementally, and progress comes from many small decisions compounding over time.

For Nami, that shows up in how quickly ideas can be tested once they’re framed well:

"With the right setup and preparation, things can go from a thought to an experiment within a couple of days."

On the Platform, the same mindset manifests differently. Speed matters less than predictability. As Felix puts it:

"It’s not flashy, just a steady, reliable setup that lets us move without unnecessary risk."

Much of this work is easy to miss from the outside. It lives in experiments that quietly accumulate signal, pipelines that run before anyone notices, and features that evolve without breaking what’s already there.

For engineers who care about how systems behave in production - not just how they launch - this is a place where that mindset is valued and put into practice.

If this way of working resonates, there’s more happening here: explore open roles.

Inside Bolt Berlin Engineering: How teams build global mobility products

We’re hiring!

Recent posts

Bolt and Stellantis to scale autonomous vehicles in Europe