Bolt serves more than 200 million customers in 600+ cities. Much of the code behind its rides, deliveries, and rentals is written in Tallinn, where Bolt is headquartered.

At this scale, there’s no such thing as a harmless small change. A single deploy can stall a market, yet a 100 ms optimisation can save users thousands of hours a year.

This is the everyday reality for engineers like Madis Peetersoo (Engineering Manager, Delivery), Jana Lutus (Junior Software Engineer, Mobility), and Laura-Eliise Marrandi (Junior Software Engineer, Mobility).

Tiny changes, massive blast radius

Bolt runs a dense mesh of services: search, matching, routing, pricing, incentives, fraud, sign-up, payouts. The job is to make that complexity feel instant.

Few people understand this better than Madis Peetersoo, an Engineering Manager working on Bolt Food.

For him, the biggest adjustment after joining wasn’t language or framework. It was scale.

“A tiny change doesn’t look tiny anymore when you know thousands, if not millions, of people will be impacted.”

That complexity shows up even in everyday features. Madis likes to use a concrete example, searching for the best Tiramisu in Tallinn:

You need to store thousands of menus in a searchable, context-aware way.
You have to define best differently for each user and city, based on factors like distance, rating, delivery fee, order volume, and time of day.
Then you need to serve results in a few hundred milliseconds, on anything from the newest iPhone to a budget Android device.

All of that happens across near-real-time systems, distributed architectures, and shared services used by multiple product lines.

To keep this under control, teams don’t just watch uptime. They track:

Business metrics like conversion, registration completion, and order success.
Technical metrics like latency, error rates, and slow queries.
Team signals like PR review speed and time from merge to production.

Code ships daily and reaches users almost immediately. When something slips, the graphs move. And engineers often feel it themselves in the app. The goal is to catch regressions before users notice them.

When a safe change isn’t safe at scale

Serious incidents are rare. Changes are peer-reviewed by engineers who live with this complexity every day. But in a tightly interconnected system, even well-understood updates can have unexpected consequences.

Jana Lutus (Junior Software Engineer, Mobility) saw this during an update to authentication-related secrets. The change itself looked routine. But shortly after deployment, all existing user sessions were invalidated. More critically, users couldn’t log back in at all.

“Tens of thousands of users were suddenly locked out,” she explains. “Authentication is a shared dependency, so the issue didn’t affect one service. It spread across a large part of the system.”

The impact was immediate. Once the scope was clear, the team split ownership of the affected services and redeployed them one by one, closely watching metrics as access was gradually restored.

What stood out most wasn’t panic, but coordination.

“Everyone knew their role,” Jana says. “Communication was clear, and the focus stayed on solving the problem together.”

Afterwards, the team reviewed what went wrong and tightened how shared authentication changes are staged, reviewed, and rolled out. “It was stressful in the moment,” Jana admits. “But it was incredibly valuable.”

Shipping fast, even when you’re new

New engineers in Tallinn usually deploy to production in their first week. There’s structured onboarding, but no long shadow phase where your code doesn’t matter.

Laura’s internship project was an internal view showing where features were enabled by country and city. It forced her to understand the system and deliver something operations relied on.

As a full-timer, her first product change was migrating an old driver admin page to a new panel under a hard deadline.

“I spent time talking with operations to understand what they needed,” she says. “We shipped on time, and they were genuinely happy. That first win mattered a lot.”

Soon after, she owned a mid-sized feature explaining to drivers exactly why documents were declined, so they could fix issues faster.

“The task was more difficult than I expected,” she says. “But once it was live, we saw a clear increase in completed registrations. That’s when the scale really hits you.”

Both Laura and Jana learned the same lesson early: speed only works if you surface what you don’t know.

“At first, I tried to solve everything alone,” Laura admits. “Eventually, I’d ask for help and realise I never had enough context. Asking questions sooner changed everything.”

Turning bottlenecks into systems

Not all engineering problems are technical failures. Some are process bottlenecks.

Jana’s team built an automation product that initially had no UI. Every rule and market-specific configuration had to be written directly in the backend by engineers. As requests grew, this stopped scaling.

Their tech lead flipped the approach. Instead of pushing more work onto engineers, he taught Jana and another product specialist to implement changes themselves.

With mentoring and reviews, they started writing production code.

“I’ll never forget seeing the first market fully configured by me go live,” Jana says. “And the first driver registration automatically accepted there. It took thousands of lines of code.”

That moment helped confirm her path into engineering.

Ownership without chaos

Ownership at Bolt isn’t a slogan. It’s the default.

Engineers are involved from the moment a problem is defined. If you see something broken and know how to fix it, you don’t wait for permission.

“In many companies, engineers are told what to build,” Jana says. “Here, we help shape the solution from the beginning. We’re expected to challenge ideas and speak up.”

The guardrails are practical:

Clear ownership of services
Design docs for risky changes
Metrics that make silent failures hard to ignore

You can move fast, as long as you can explain what you’re changing, why it matters, and how you’ll know if it worked.

Learning systems, with help from AI and people

The codebase in Tallinn is large enough that switching teams can feel like moving cities.

When Madis changed teams after almost three years, AI helped him ramp up faster by navigating the most important parts of the new codebase and digging through logs. Laura uses it as a thinking partner for planning and example code.

But none of that replaces people.

Career switches like Jana’s work because tech leads invest time. They explain logic, challenge assumptions, and build confidence, not just features.

And between metrics, dashboards, and incident reviews, there’s a ritual that keeps everything grounded.

Lunch.

“It’s refreshing and bonding to go out together,” Madis says. “You switch off for a moment, hear how others are doing, and celebrate wins.”

Those moments matter when your code is wired into a system that never sleeps.

Who thrives here

Engineers who tend to enjoy working at Tallinn HQ:

Are comfortable with a global blast radius
Enjoy near-real-time systems and messy constraints
Like owning features end-to-end
Ask questions early and learn fast
Use AI and metrics to move quicker, not hide risk

The work is demanding, often invisible to users when done well, and tightly coupled to real-world outcomes. Madis joined for the technical complexity and scale. Jana and Laura stayed for something else, too: the freedom and responsibility to change both the system and their own paths within it.

If that balance of complexity, ownership, and consequence resonates with you, take a look at roles in Engineering, and our guide to relocating to Tallinn.

Open roles

Relocation to Tallinn (visas, housing, logistics)

When one deploy can lock out millions. Engineering at Bolt in Tallinn

We’re hiring!

Recent posts

Bolt and Stellantis to scale autonomous vehicles in Europe