Every engineering team has an unofficial "translator." I got tired of being mine
Every engineering team I've worked on has had the same unspoken job title. Nobody's hired into it. It just lands on whoever's been there longest and answers Slack the fastest.
The translator.
Someone in support pings: "what happened to order #4421?" The translator opens five tabs. Application logs. Sidekiq dashboard. Database. A few greps. Twenty minutes later they paste back: "shipping address validation failed because the customer's postcode hit the new regex, then the retry job ran 3 times, then we rolled back the order."
The support person says thanks. The customer gets an answer. The translator goes back to whatever they were doing before they got pulled out of focus.
This is the actual cost of "observability." Not the bill from Datadog. The bill from your senior engineer's attention.
I got tired of being mine. So I built the thing that does the translation.
Three observations from a few months in:
-
The hardest part wasn't the translation. It was correlation. Stitching the Sidekiq/Active job that ran 4 seconds after the HTTP request to that specific request. Making a GlobalID resolve back to "User #42 (Razvan)" instead of gid://app/User/42. Same event, captured by two different agents (Ruby and Next.js), has to produce byte-identical output on the server. None of that demos well. All of it has to be right.
-
People assumed there was an LLM in the middle. There isn't. The translation is deterministic. Templates plus correlation, same input in, same sentence out. AI summaries are an optional layer on top. Took me a while to figure out that "deterministic" was the actual selling point for buyers who'd been burned by AI-product cost surprises.
-
The free tier includes an MCP server. So when someone asks Claude or Cursor "what happened to order 4421 in my app?", the agent can answer the same way a human reading the dashboard would. That changed how I think about the product. It's not just a log viewer. It's an answer surface for any reader, human or agent.
If you've ever been the translator on your team, curious whether this resonates or whether I've just described a problem only my brain has.
Wrote a longer version of the thinking here, in case anyone wants the full thing:
This resonates.
The sharpest part is not the log translation itself. It is the interruption cost.
Most observability tools sell to the person investigating the issue. Your post is really about the person who should not have been pulled into the investigation in the first place.
That is a stronger category angle than “log viewer” or even “AI observability.”
Something closer to: incident explanation for the unofficial translator on the team.
The deterministic part matters too, because it makes the product feel reliable enough for support, ops, and agents to use without creating another “AI guessed wrong” problem.
Small thing I’d be careful with: don’t bury that positioning under MCP/LLM/devtool language too early. The buyer pain is the senior engineer getting dragged out of focus because nobody else can understand what happened.
Happy to put the tighter positioning angle in writing if useful.
This is the sharpest pushback I've gotten on the positioning yet.
You named something I've been circling: the buyer isn't the engineer running the investigation, it's the person tired of authorizing senior engineers to keep getting pulled into investigations. Different pain, different budget. "Incident explanation for the unofficial translator on the team" is closer than anything I've written.
The pattern I've seen so far isn't always the CTO. Sometimes the founder, sometimes head of support, sometimes the lead engineer who's tired of being the bottleneck. Have you seen one of those segments convert notably faster, or is it more about the language and letting the buyer self-select?
And yes, would take you up on the positioning writeup. DM whenever. Razvan
Appreciate that, Razvan.
That segment question is exactly the part I would not answer casually, because founder, support lead, CTO, and lead engineer all buy for different reasons.
DM/email is better. I’ll write the cleaner version around the buyer, the pain language, and which segment I’d test first before the product gets framed too broadly.
Stop over-engineering. Just build with whatever gets you to market fastest. I shipped my entire automation suite using just Make, Notion, and a Telegram bot. No code, zero server maintenance, and took me just a few days. Don't waste weeks writing custom backend code before you even have a single paying user.
Appreciate the principle, agree that shipping fast and using the lightest stack possible matters.
The thing being built here isn't really a no-code shape though. It's a Ruby gem that hooks into Rails apps and captures HTTP requests, Sidekiq jobs, and ActiveRecord callbacks at the framework level, then correlates them. Make, Notion, and Telegram bots can't reach inside a Rails process to read GlobalIDs from job args or stitch a DB callback to the request that triggered it 4 seconds earlier. Different layer entirely.
Also worth flagging: the gem is already shipped to RubyGems, the dashboard is live at ezlogs.io, and there are paying users. So "don't waste weeks before a single paying user" doesn't quite apply here either.
The post wasn't about the build choice. It was about positioning, what the actual buyer pain is. Happy to talk no-code tradeoffs if you've shipped something with similar event-capture needs though.