The Observability Trap: Why I Built Lapsoss to Break Vendor Chains

The Year is 2020… or Maybe 2021

I don’t remember the exact date - COVID made time blur together. But somewhere in that pandemic haze, I made the mistake of replying to LinkedIn messages from sales representatives. Pattern Parasites, as I call them now. Whether it was the isolation, the kombucha, or just the chaos of those years, I engaged.

I was deep in the trenches, trying to do the “cool thing” - migrating from metal to serverless. But the paradigm shift was brutal. Everything that worked before was crumbling. That’s when they struck.

“We have a well-tested SDK that’s helped thousands of clients migrate in weeks, not months.”

Music to my desperate ears.

The Seduction Phase

They all have the same playbook - Datadog, Sentry, New Relic, AppSignal. It goes like this:

1. The Free Trial: “Try us risk-free for 30 days!” They know 30 days isn’t enough. You can’t even compare two months of data. During that month, you have unlimited everything - unlimited checks, unlimited monitors, unlimited joy. Then reality hits: Standard plan? 1-2 checks. Premium? Maybe 10. Unlimited? Costs more than a developer’s salary.

2. The Certifications: “Get your team trained and certified!” Translation: Bring your team for brainwashing sessions where we’ll convince them our product is the only way. They’ll feel obligated to use it because of the certificate we gave them and that 16GB USB from AliExpress that’s actually 4GB with our logo.

3. The Migration Promise: “Our SDK makes it seamless!” Sure, if your project is basically empty or exactly matches our demo template. Real-world applications with actual complexity? Good luck with that seamless migration.

4. The Success Stories: “Companies like yours are already seeing 10x improvements!” They take enterprise clients with already-terrible infrastructure, have their QA teams generate synthetic metrics, then claim it’s a success story. “Monsanto reduced errors by 90%!” Yeah, from catastrophic to just terrible.

I signed up. Convinced my team to take their training. We were going TO THE MOON in observability.

The Reality Check

I started ripping out thousands of lines of code. Every place where I had custom tracing, benchmarking, breadcrumbing - gone. Replaced with their “battle-tested” SDK.

An SDK ported to Ruby by Java developers who used lambda patterns everywhere because that’s what they knew. We don’t do that in Ruby. We have blocks, procs, and a completely different idiom. They couldn’t even tell the difference between bundler and pip.

The support experience was a comedy of errors:

Round 1: I mention Nuxt.js. They send React docs. Then NEXT.js docs. When corrected: “Hundreds of our customers use Nuxt.js!” Sure, that’s why you’re sending docs for the wrong framework.

Round 2: I ask for help tracing Trailblazer gem operations - I need timing for each step. Their response? “Thank you for your patience. We’ve identified that you’re using Salesforce Trailblazer. Unfortunately, our Salesforce specialist is currently engaged with enterprise clients, but we can schedule a consultation in Q3. In the meantime, we’d be happy to offer you our Salesforce Integration Certification course at a 20% discount.”

They literally just Googled “Trailblazer” and went with the first result.

The kicker? I’m a core member of the Trailblazer gem organization. I could have shaped the gem to be more observable without any hacks. But they were too busy trying to sell me Salesforce training to realize they were talking to someone who maintains the actual technology.

Ruby wasn’t their target market. It was a checkbox. “Multi-language support? ✓”

Then came the fine print.

The free trial activated the moment I created the account - no time to prepare, learn, or plan. To get any discount, you had to prepay annually. Fully. Up front. Rigid device limits meant every new server cost extra.

That $10K? That wasn’t for usage. That was the minimum I’d pay whether I used their service or stared at a blank dashboard all month. Like renting an apartment where you pay full price even when it’s empty, then get charged extra if a friend visits.

Want to run a simulation to test your setup? Surprise invoice. Every test, every spike in traffic, every attempt to validate your monitoring - all extra charges on top of your minimum.

The Ghosting

Seven months in, I’d had enough. I emailed my sales contact to cancel.

Silence. Complete radio silence.

Then, one month before what would have been my renewal, suddenly she’s back: “Hope you’re enjoying the platform! Ready to discuss your renewal?”

I hadn’t used their service in 5 months. My account was terminated, supposedly deleted. But somehow they still had me in their sales pipeline, ready to win me back.

The Creepy Comeback

Fast forward to 2024. New sales rep. New pitch. Same company.

“I’ve reviewed your dossier and I’d like to offer you three months free trial.”

I declined, explaining I’d never return to corporate vendor slavery.

He waited a few days, then: “I looked at your account configuration. You weren’t using the platform correctly. You weren’t taking full advantage…”

Wait. What?

How was he looking at an account I deleted years ago?

When I pointed out we use Nuxt.js, same confusion as the first consultant years earlier. He sent React instructions. Then pointed me to an abandoned open-source module for Nuxt 2. We were on Nuxt 3 by then.

That’s when I knew. These weren’t service providers. They were data hoarders with a subscription model.

The Leverage Game

Without lock-in, vendors have no leverage. I learned this the hard way when helping a client migrate off a major cloud provider. Their response?

“Good luck migrating away from us.”

They knew we had dozens of services exclusive to their platform. Years of accumulated technical debt. Custom integrations that would take months to rebuild. They had us by the throat, and they knew it.

That’s the real product they’re selling: leverage. Once you’re deep enough in their ecosystem, they can raise prices, degrade service, or change terms - and you’ll take it. Because the alternative is a migration nightmare they’ve carefully engineered.

The $500K Dashboard Nobody Watches

At one consulting gig, I discovered the ultimate absurdity. This company had:

• Airbrake for one team
• Sentry for another
• Bugsnag for the mobile team
• AppSignal for the ops team
• Datadog for “executive visibility” - the new kid promising more features

Legacy systems were never migrated. Each team kept their preferred tool.

The truly absurd part? Some teams built engines with vendor-specific SDKs. When you mounted these engines into a monolith app, you got every SDK monkey-patching the same dependencies - in whatever order they happened to load. The last one to load won the patching war. Pure chaos.

Hundreds of thousands of metrics. Dashboards linking to dashboards linking to dashboards. $500K per year.

How often did they check these dashboards? 2-3 times per month.

To be fair, these rare companies aren’t just buying software. They’re essentially hiring a dedicated team within each vendor. Four engineers from Datadog who can assist 24/7. A support team that knows their infrastructure by name. It’s an outsourced observability department.

But here’s the thing: most companies paying these prices aren’t getting that level of service. They’re paying enterprise prices for the same SDK everyone else uses, just with a higher rate limit.

When I proposed consolidation through a vendor-neutral layer, the defenders of the status quo emerged. “Untested!” they cried. “Not battle-hardened!” One even threatened to quit if we implemented my solution.

The Birth of the Liberation Stack

That’s when I started building what I call the Liberation Stack.

Initially, I was building a full open-source Rails server to receive all the errors. It was hacky - scaffolded interface, mostly using it from a TUI. I open-sourced it and left it for two weeks without any announcement, just to see what would happen.

Then I opened Twitter/X to post a survey about error tracking needs. That’s when I saw Kyrylo Silin (@kyrylosilin) announcing Telebugs - pay once, own it forever. Less than $1 per day over a year.

I immediately made my Rails app private and pivoted. Why? Because I realized a platform requires massive work - team management, alerting, integrations, SAML, permissions, all that enterprise cruft. Kyrylo had already built that. Better to focus on what was really needed: the adapters.

The first Liberation Stack module was born: Lapsoss.

The name comes from LAPSUS (a slip, an error) and OSS (Open Source Software). Because this will always be open source. It will never become a company. It cannot be bought, acquired, or shut down.

The idea is brutally simple: When I want to switch providers, it takes minutes or hours. Not weeks. Not months. The API stays the same. No vendor-specific interfaces creating side effects. No refactoring because someone raised prices or discontinued service in my region.

Liberation Stack: An Idea, Not an Enterprise

Let me be crystal clear: The Liberation Stack isn’t a business. It’s an IDEA. It doesn’t need funding. It doesn’t need investors. It doesn’t need a business model.

What it needs is to exist.

This gives power to that developer in Africa who can’t afford $10K minimums. To that startup in Asia bootstrapping on $500/month. To that student in South America building their first production app.

With Lapsoss, you can test-drive 3-4 providers using their free tiers. Compare them with real data. Then either:

• Pick the one with the best service for your needs
• Go with a self-hosted solution
• Build your own simple endpoint

The best error tracker? One that sits idle because your app has no errors.

We’re not building a company. We’re democratizing access to professional tooling.

The Manifesto

Here’s the deal I’m proposing to the industry:

You are a service provider. You adapt to standardized patterns. We don’t refactor our codebases for your quarterly revenue targets.

Want special features? Extend your adapter. Want to innovate? Great - do it in your dashboard, not in my codebase.

The Update Fatigue

Let me be clear about SDK updates. I need them for:

• Bugs: Yes, fix what’s broken
• Security: Absolutely, patch vulnerabilities
• Performance: Sure, make it faster

I DON’T need SDK updates for:

• AI Monitoring: I didn’t ask for it, don’t force it on me
• DDOS Warnings: I have Cloudflare, thanks
• More Telemetry: Stop training your AI on my stack traces
• Premium Features: That I can’t even access on my plan
• Growth Metrics: Your OKRs are not my deployment risks

Every week there’s a new release. Each one adding features designed to justify the next price increase. Each one a potential breaking change to my stable system.

Vendor Engineers: The Other Victims

I need to say this: the engineers at these vendors are victims too. They’re talented people trapped in a psychopathic growth-at-all-costs system.

Imagine being forced to add “features” nobody wants because quarterly earnings are coming up. Being told to instrument more of the customer’s stack not to help them, but to increase lock-in. Writing code you know makes the product worse because “engagement metrics” demand it.

They joined to solve interesting distributed systems problems. They ended up building subscription traps.

To those engineers: You’re not the enemy. The business model is. And yes, you can join the resistance too.

The Liberation Stack Roadmap

Lapsoss is just the beginning. The Liberation Stack isn’t about reinventing every wheel - it’s about ensuring no wheel can trap us.

What Already Exists as Standards:

• OpenTelemetry: Already a vendor-neutral standard for tracing. I’m not reinventing it - I’m adopting it.
• Prometheus: Open metrics format that works. Use it as-is.
• OpenAPI: API specifications that remain free. Keep them.

What Needs Liberation:

• Error Tracking: Hence Lapsoss - because every vendor has proprietary APIs
• APM Dashboards: Vendor-specific visualizations that lock in your data
• Alert Routing: Each vendor’s unique alerting syntax
• Session Replay: Proprietary formats everywhere

The Liberation Stack is a collection of modules, not a monolith. Some we build, some we adopt, some we fork.

The Fork Doctrine: If any module in the stack starts behaving badly - gets acquired, goes closed-source, adds telemetry, becomes a Pattern Parasite - we fork it, rename it, and let the parasitic version dry out in the sun. The community moves to the fork. The parasite withers without hosts.

Each module will be:

• Completely separate and focused
• Donated to foundations (Apache, Linux Foundation, or similar)
• Legally protected from patent trolling
• Impossible for any entity to control or bully

The goal isn’t to create another vendor. It’s to create an unownable ecosystem where good standards thrive and parasitic ones die.

Why Foundations Matter

By donating these projects to established foundations, we ensure:

• No single company can acquire and kill them
• No VC can turn them into the next vendor lock-in trap
• No patent troll can claim ownership
• No movement can hold them hostage

This is bigger than error tracking. It’s about proving that critical infrastructure can be truly community-owned.

Simplicity Is The Feature

Lapsoss didn’t invent anything. I studied existing error tracking gems, extracted the core concepts, and rebuilt them using the Rails stack we already know and love.

No exotic patterns. No custom DSL to learn. No 500-page documentation.

What you “lose”:

• Telemetry you didn’t ask for
• Being spied on
• Complexity masquerading as features
• Weekly SDK updates

What you gain:

• Learn Lapsoss once, use it forever
• Never learn another error tracking framework
• Migration is just sed/grep because we use standard patterns
• Benchmarks that show minimal overhead (check the docs folder)

The feature set is complete. Error tracking doesn’t need to be complicated.

Lapsoss: Pre-1.0 and Proud

Today, I’m releasing Lapsoss - still pre-1.0, and that’s intentional. It works on my machine. It handles errors. It talks to multiple providers. It doesn’t monkey-patch your application into oblivion.

Here’s my commitment: Once we hit v1.0.0, that’s it for breaking changes. The gem will be stable. Patch versions for bugs only. New major versions will only appear when new versions of Rails or Ruby offer features we can actually benefit from - not because we need to justify our existence with constant updates.

No weekly releases. No feature creep. No growth metrics disguised as improvements.

# Your code never changes
Lapsoss.capture_exception(error)

# Monday: Using Sentry
config.use_sentry(dsn: ENV['SENTRY_DSN'])

# Tuesday: Switch to Datadog
config.use_datadog(api_key: ENV['DD_API_KEY'])

# Wednesday: Run both for comparison
config.use_sentry(name: :primary)
config.use_datadog(name: :comparison)

# Thursday: Drop whoever disappointed you
# Just remove the line. Zero code changes.

The Challenge to Vendors

Here’s my challenge to Datadog, Sentry, New Relic, and the rest:

Stop trying to own our codebases. Start competing on actual value.

Build better dashboards. Provide better insights. Offer superior alerting. Compete on your strengths, not on how deeply you can embed yourselves into our applications.

The age of SDK monopolies is ending. The era of the Liberation Stack has begun.

The Universal Envelope Vision

In future versions, we’ll have a universal envelope - built by the community, free of charge, royalty-free, and LLM-optimized.

The endgame isn’t custom adapters forever. It’s forcing all providers to accept a standard sink. They provide the endpoint, you decide what to send. No more vendor-specific SDKs. No more proprietary formats. Just a universal data envelope that every service must accept.

I’ve tested this pattern beyond Ruby:

• Go: Clean interfaces, zero dependencies
• JavaScript/TypeScript: Pure functions, no framework lock-in
• Dart/Flutter: Unified error handling across platforms

If you’re a veteran in any language, reach out. We can build lapsoss-python, lapsoss-rust, lapsoss-whatever. Not to create more adapters, but to prove the pattern works everywhere. Once enough languages adopt it, vendors will have no choice but to support the standard sink.

Multi-Provider Magic: Not a Bug, It’s THE Feature

Lapsoss doesn’t handle “duplication” - it sends to ALL configured providers simultaneously. This isn’t a limitation, it’s the whole point:

Migration Without Downtime:

# Run both while transitioning dashboards
config.use_sentry(name: :old_provider)
config.use_datadog(name: :new_provider)
# Compare them side-by-side with real data

GDPR Compliance Made Simple:

# Route by region
config.use_sentry(name: :eu, dsn: ENV['EU_DSN'])  # EU errors to EU servers
config.use_rollbar(name: :us, dsn: ENV['US_DSN']) # US errors to US servers

A/B Test Your Providers: Test 3-4 providers with real production data. See who actually delivers value. Then pick one, or none.

Own Your Errors, Literally

With Lapsoss, you can go full self-hosted:

Open Source Solutions:

• GlitchTip: The closest Sentry alternative - uses Sentry SDKs, fully open source
• Errbit: The OG self-hosted solution, Airbrake-compatible
• Bugsink: Sentry-compatible, built for privacy-conscious teams
• OpenObserve: Full observability with error tracking, 140x cheaper storage than Elasticsearch
• SigNoz: Complete observability stack with error tracking included

Pay Once, Host Forever:

• Telebugs: Less than $1/day over a year - no subscriptions, no recurring fees

Roll Your Own:

• Your Own Backend: A simple POST endpoint that stores JSON. Throw in Grafana if you’re feeling fancy. That’s literally what you’re paying $500K/year for

You own the data. You own the infrastructure. You own the decisions.

No sales rep can access your “deleted” account. No vendor can surprise you with invoices. No company can hold your error data hostage.

I Have a Dream

I have a dream that one day, AI assistants will write error handling code using universal patterns - not because they were force-fed millions of pages of vendor documentation by venture capitalists, but because the patterns are genuinely universal.

I dream of a world where an LLM doesn’t need to know whether you’re sending errors to localhost, a self-hosted server, or a Docker container running on a CubeSat orbiting Mars. The pattern remains the same. The freedom remains absolute.

As Martin Luther King Jr. spoke of judging by content of character, we should judge code by elegance of pattern, not by vendor of origin.

This isn’t just technical architecture - it’s digital civil rights. The right to own your errors. The right to switch providers. The right to be free from the tyranny of SDK monopolies.

“The arc of the tech universe is long, but it bends toward open standards.” And we’re here to bend it faster.

Join the Resistance

Lapsoss is live. The code is on GitHub. The gem is on RubyGems.

This isn’t about replacing these vendors - they serve a purpose. This is about ensuring they serve us, not the other way around.

To developers: Every gem 'lapsoss' added to a Gemfile is a vote for developer freedom. Every vendor adapter contributed is a step toward true portability.

To vendor engineers: You can join the resistance too. Help us build the standard you wish your company would adopt. Contribute anonymously if you need to. Show your leadership what customers actually want by helping build it.

To vendors themselves: Adopt the standard. Be the first to say “we support the universal envelope.” Compete on your strengths - better dashboards, superior analytics, faster response times. Not on how deeply you can embed yourselves in our codebases.

The Pattern Parasites have had 25 years since 1999 to lock us in. Now it’s our turn to break free.

This is part of the Atlas Monkey universe - where resistance isn’t just possible, it’s inevitable.

P.S. To the sales rep who somehow still has access to my deleted account data from 2020: That’s not a feature. That’s a GDPR violation waiting to happen.

P.P.S. To those who defend vendor lock-in as “battle-tested”: The community’s solution is the future you’re afraid of.

P.P.P.S. Posted from my jailbroken Amazon Kindle running a 3.x kernel. Because even my e-reader refuses vendor lock-in.