Lessons from the deep end

Spatie has been part of the Laravel ecosystem for years, releasing over 300 packages, publishing many blog posts and courses, and growing with the community. We started building Flare in 2018 with 7 employees; today we’re 11, still balancing client work with our OSS projects and products like Flare, Mailcoach, and Ray.

20 months ago, we started building Performance Monitoring as Flare’s next big feature, never expecting Laravel’s rapid commercial growth to put us in direct competition with their own tools. This is our honest take on those 20 months went, how we’re adapting to this new reality, and where we’re heading next while staying true to who we are. A dive into the deep end, without knowing how far down it goes.

Why we jumped

Many other exception trackers at the time felt bloated and didn’t focus on Laravel. We started building Flare as an easy to use, and context-rich alternative built to support Laravel, the framework we have been using for years at that point. Flare has grown into a tool that we use and love here at Spatie every day. Using our own product meant that we were able to improve it over the years by adding features and context that we were missing. This made both Flare and Ignition (our standalone error page, which was the default in Laravel until 2024) to become more powerful and usable over time.

Early on, we had big ideas about expanding Flare beyond just collecting exceptions from failed requests. We are already collecting rich context for them, why not collect the same data for sampled requests, jobs and commands? With new tracing standards like Open Telemetry emerging from 2019, adding performance monitoring felt like a natural next step.

The turning point came at our booth at Laracon EU 2024. A first for Flare, and to add to the excitement, we were almost placed right next to Sentry. A real eye-opener was that not many attendees had actually heard of Flare or its affiliation with Spatie. This came as a bit of a surprise; apparently we had overestimated our recognition. On top of that, a lot of the conversations we had were more about monitoring and tracing integrations rather than error monitoring. This aligned with our own wishes and ideas for Flare and with our gut feeling validated, we felt highly motivated and full of ideas after the conference. Back at the office, we started working on a proof of concept for Performance Monitoring right away.

Getting caught in a whirlpool

My colleague Ruben spent just over two weeks extending the Flare client to collect trace data and cook up a nice dashboard with performance metrics for each route. At this point we were confident we could ship this thing by summer 2024.
Fast forward to February 2025 and nothing has shipped at all. Instead, we’re now moving infrastructure to Kubernetes, adding ClickHouse as a secondary time series database, adding additional ingress endpoints to monitoring data, introducing Open Telemetry support and basically rewriting our entire ingress flow for errors. This wasn’t just a new feature anymore, we were overhauling the complete product. We missed all our previous deadlines, and dedicated all of Flare’s development time to it. Features and improvements to Flare we planned in those 12 months were postponed, and we fell behind on the marketing efforts we had planned after Laracon EU.

Even with our years of experience in building projects for ourselves and for clients, we fell into many classic project management traps: scope creep, underestimating tasks, optimistic planning, losing momentum, perfection paralysis and the "while we're at it" syndrome of refactoring everything we touched. Beyond this, life also got in the way. Ruben, our lead back-end developer for Flare became a dad, and other colleagues moved on to new challenges or had to take a break from Flare. As our team’s energy waned, our momentum faded.

The reality of running a small agency adds another layer of complexity. Spatie still relies heavily on client work, and work on Flare was put on the back burner whenever client deadlines emerged. We always try to balance what our team wants to work on with what the company needs, having to shift focus far more often than we’d like. Ironically, after months wrestling with OTEL data structures and ClickHouse performance tuning, doing client work felt like a breath of fresh air.

At this point, we weren’t so sure anymore when and where we would actually land with Performance Monitoring.

Unfamiliar waters

A few months after Laracon EU 2024, things in the ecosystem we’ve been part of for years started changing quickly for us. In May 2024, a PR was made to the Laravel core removing Ignition as the framework’s default error page. September brought a $57M investment into Laravel by Accel, and November revealed Nightwatch as a first-party performance monitoring solution at Laracon AU.

While we always have maintained a good relationship with Laravel, we never had any commercial dealings with them. No secret handshakes, contracts or shared profits. Having Ignition as a default error page meant we could drive more leads to Flare, but also add useful features in the framework like sharing errors and the editor integration. This helped Flare to grow in the long term, despite having no direct commercial ties to Laravel.

With Ignition being gone, Laravel backing Sentry as their preferred error tracker, and launching Nightwatch, it felt like your big brother passed you in a race you only just realised was happening. Our commitment with Laravel as the open-source framework remains unchanged. However, the reality is that we are now working with (and competing against) Laravel being a commercial entity.

We get the push toward a more commercial focus, and competition is only natural. But to be building quietly while our competitor was showing off their product to a wide audience was frustrating. It’s hard to stay excited about a private beta when others are stealing the spotlight.

To sink or to swim

These announcements made us look inward and reconsider our plans for Flare. Is now even the right time to build and release performance monitoring, or is it now or never?

I remember difficult discussions we had with the entire Spatie team which had colleagues feeling disappointed both with the situation and the perspective of reconsidering Flare’s future. But at some point we decided to power through. It might’ve been the sunk cost fallacy or stubbornness that led to the decision to not back down, but I think it’s simply because we truly believe we’re building a great product.

Looking back, it's easy to view these developments as setbacks, but they helped us to build something better. While we didn't abandon our initial idea, these new circumstances caused us to make different decisions that improved both our performance monitoring and Flare as a whole:

• Refactoring everything to be OTEL compliant, believing this will become a key differentiator for Flare
• Adding the same in-depth monitoring context to our error reporting data, making existing Flare features even better
• Switching to ClickHouse to make performance monitoring more performant
• Bringing Zuzana onto support to free up developer time for building
• Starting to containerize our infrastructure to enable fully European servers
• Most importantly: committing to keep investing time, money and energy into Flare

We realize that we should’ve shipped sooner and kept the scope smaller (there are only a million blog posts with this conclusion). But at this point, we’re developing something valuable enough that deserves to exist alongside competing products like Nightwatch, or Sentry. The market is large enough for different approaches to monitoring, and with the $57M investment in Laravel, the ecosystem and community will keep growing.

Swimming back to shore

In the short term, we're working hard to make performance monitoring available to all our users. In the longer term, we are adapting to the new reality without abandoning Flare. By not trying to outcompete Laravel or match their resources, we can focus on doing what we do best and take a different approach.

As a small team, we've eliminated the middleman entirely. Our engineers answer your Flare questions directly, help you integrate with complex legacy applications, and build features based on real conversations with users. When you need support, you're talking to the people who actually wrote the code (or these blog posts).

As a European company, we bring an actual European perspective on data protection, GDPR compliance, and privacy. We can make decisions quickly based on what's right for our users, not what's commercially most interesting. As a team we also like having European alternatives to software and tools.

As Laravel and OSS contributors, we've spent years plowing through the framework's internals and building Laravel-specific packages, integrations and projects. Our 300+ packages give us insights and ideas on what to integrate into Flare next and how to do it. And we're not scared of exploring better integrations with other (PHP) frameworks and products.

We continue to invest time and energy in Flare and our marketing efforts. Although we were too quiet in the past and relied too heavily on Laravel and Ignition for growth, we are now moving forward and telling our own story. If nobody knows you exist, it doesn't matter how great your tool is.
In line with adapting, here’s what’s next:

• Ignition returns as open source: Losing Ignition as Laravel’s default error page cost us leads, but also our favourite error page. We’re bringing it back and expanding it with the same rich debugging context we collect for Performance Monitoring.

• Exploring an open source Flare: Open source lies at the heart of who we are at Spatie and of our success. Making Flare’s code public will reveal how we grew a “simple feature” into a complete product.

• Releasing Performance Monitoring for free: Performance Monitoring is currently in public beta and available to all users. Once released, it will be included for free in every plan. Combined with Flare’s existing error tracking, you're now essentially getting two powerful products for the price of one.

The last 20 months have taught us that jumping in at the deep end isn't always about having perfect timing or ideal conditions. Sometimes, it's about having the conviction to keep swimming when the going gets tough.