In this episode, our host Jan Meissner sits down with Alex Ratman, Senior Software Engineer at Mews and a self-proclaimed observability enthusiast. Alex shares the story of how a performance gap on the customer side led his team to build the first true observability solution for frontend engineering at Mews—moving from being “blind” to having eyes on every interaction. The conversation goes deep into the “Why” behind the massive migration from New Relic to Coralogix. Alex explains the three-pronged decision: solving the cost problem, closing data gaps that large-scale platforms often miss, and finding a partner that offers the support needed to teach developers a whole new discipline. They also discuss the human side of tech: The Frontend Observability Kindergarten. Alex breaks down why he started a “kindergarten” to teach the basics, his tips for running a successful engineering guild, and how his team uses AI (and Coralogix’ MCP server) to create POCs that give engineers hints on where to start an investigation.
————————————————————————–
To learn more about Jan and Alex, go to:
Jan Meissner
Alex Ratman
Introduction
Jan:
Hello and welcome to another episode of the Mini R&D Podcast.
Today, I’m joined by Alex Ratman — a Senior Software Engineer and someone I strongly associate with one word that’s been resonating a lot lately: observability.
Alex, welcome.
Alex:
Hello, and thank you for having me.
How Alex Got Into Observability
Jan:
How did observability become your thing? Was that always your focus at Muse?
Alex:
First of all, I’m glad to hear that association — and thank you for mentioning it. Observability is very important to me.
I joined Mews in late 2021 as part of the Productivity team, which at the time was responsible for developer experience for frontend engineering.
A year or two later, we started dealing with customer-side performance issues. At that point, we were somewhat blind — we didn’t have enough visibility into what was happening in production.
The natural place to start was the platform we were already using at the time, New Relic.
That’s where the whole observability journey began.
Our team was chosen to build the first frontend observability solution. We researched several options, explored alternatives, and ultimately built an initial solution.
After a few months, we became the team recognized as responsible for frontend observability.
Why Observability Matters
Jan:
You say your team was chosen, but clearly this was something you genuinely enjoyed.
What does observability mean to you — maybe even philosophically?
Because as a software engineer, you usually focus on fixing things. With observability, you’re almost giving the system eyes.
Alex:
That’s a great way to put it.
For me, this was always a personal preference.
Not every frontend engineer is naturally drawn to observability, and that’s completely fine.
What excites me is the challenge of discovering what’s happening in a system when you initially have no visibility.
Trying to uncover signals, gather information, and figure out where to look — that investigative process is what makes it fascinating.
That’s also why I was excited to help lead the transition from New Relic to Coralogix.
From Frontend to Cross-Functional Engineering
Jan:
You started on the frontend productivity side.
Has your role expanded beyond frontend since then?
Alex:
Definitely.
I’ve always seen myself as more of a full-stack engineer, so collaborating with backend engineers, data engineers, and analysts felt natural.
A lot of it comes down to curiosity.
There are many areas of software engineering that interest me, and that curiosity has really driven my career.
That’s how I ended up here.
Making Observability Accessible
Jan:
With all the data involved, do you sometimes feel like a data analyst?
Or do you rely on embedded analysts?
Alex:
That’s actually one of the key challenges we’re solving.
With the move to Coralogix, we’re trying to make observability self-service.
The goal is for any engineer to get the information they need directly, without needing help from specialists.
There are multiple ways to gather insights — through dashboards, queries, and increasingly through AI-powered tooling.
The bigger goal is cultural:
We want engineers to proactively investigate issues themselves instead of waiting for someone else to surface the answers.
Why Coralogix?
Jan:
Why make the switch to Coralogix?
Alex:
There were three main reasons.
1. Cost
At scale, observability platforms can become expensive.
That was one practical factor.
2. Data Availability
We weren’t always able to access the level of detail we needed in our previous setup.
When you’re operating large, complex services, immediate access to reliable data is essential.
That became very clear during the performance issues that originally pushed us into this space.
3. Education and Support
This was a huge one.
Coralogix provides excellent learning resources and strong support.
That’s critical because one of the biggest challenges isn’t just implementing observability — it’s teaching people how to use it effectively.
Partnering With the Platform
Jan:
You recently hosted a workshop with Coralogix in the Prague office.
Do they actively listen to your feedback?
Alex:
Absolutely.
That’s one of the biggest differences compared to our previous experience.
They actively seek feedback and genuinely listen.
In recent weeks, we’ve been very active in sharing suggestions and improvement ideas.
They’ve been responsive, helpful, and quick to explain how things work whenever we run into challenges.
They also offer live support directly inside the platform, which makes it much easier for developers to get answers quickly.
AI and Observability
Jan:
You mentioned “AI things.”
What exactly does that mean here?
Alex:
Both embedded and external tools.
Coralogix offers its own AI feature called Olly, which we’re currently testing.
They also provide an MCP server that’s been very useful.
Personally, I’ve used it to build some proof-of-concept tools that show how AI can support investigations.
I don’t think AI will replace observability work, but it can provide strong hints about where to start investigating.
And that’s incredibly valuable.
Building an Observability Culture
Jan:
Once an engineer sees something in Coralogix, what happens next?
Alex:
We encourage people to explore, ask questions, and experiment.
A big part of this is the initiative that Terry Brown, Director of Engineering for Platform Engineering, helped establish.
We created support structures where engineers can ask questions, meet with observability specialists, and solve issues together.
The goal is to make learning collaborative.
The Frontend Observability Kindergarten
Jan:
Your team also runs guild meetings.
How does that complement the tooling?
Alex:
It works really well.
We’ve been running the Frontend Observability Kindergarten initiative for more than two months now.
We regularly gather 10–20 engineers.
Some actively participate, others just listen — and that’s completely fine.
At some point, they’ll need these skills, and simply being exposed to the concepts is already valuable.
Alongside that, we also have the Observability Champions Group, a more focused group responsible for going deeper and helping their teams.
Why “Kindergarten”?
Jan:
I have to ask: why call it kindergarten?
Alex:
The name is intentional.
Frontend observability is still relatively new for many engineers.
We’re starting with the basics.
That’s why it’s kindergarten.
But hopefully, in 6–12 months, it evolves into a university.
That’s the goal.
Advice for Running Successful Guilds
Jan:
Running guilds isn’t easy.
Any tips for making them successful?
Alex:
I’m still collecting feedback, so I’m always open to suggestions.
But if I had to highlight one thing, it’s this:
The topic matters.
People engage when the topic is directly relevant to their daily work.
Practical examples are especially important.
When people can see exactly how a tool solves a real problem, adoption becomes much easier.
I also try to share context before meetings so people can come prepared.
Initially, I focused heavily on familiarizing people with the platform itself.
Going forward, I want to expand into observability theory, practical workflows, and more AI-related applications.
What’s Next?
Jan:
What’s next for you and your team?
Alex:
My team is evolving right now.
We’re starting to build our own core services, which gives us a perfect opportunity to dogfood the observability solutions we’ve been recommending.
I’m really curious to see how that plays out.
It should also become a strong example for other engineering teams.
The Bus Driver Dream
Jan:
I have one final question.
When you joined, you mentioned that your dream was to drive a bus.
When is that happening?
Alex:
When observability at Mews reaches the highest possible level, I promise I’ll start driving buses again.
Jan:
Perfect.
You can take the Kindergarten on a school trip.
Alex:
Exactly.
Closing Thoughts
Jan:
Alex, thanks for joining.
As always, if you’re at Mews, feel free to reach out to either of us internally.
And if you’re outside Mews, you can find us on LinkedIn.
One important question:
Do you actually reply there?
Alex:
Yes — you’ll get an answer.
Jan:
There you have it.
Thanks again.
Alex:
Thank you very much.