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.
Hey Aryan,
Appreciate you offering to write that up. [email protected] if you'd rather email, or keep it on IH DM, your call.
To save you context-switching: the four buyer segments I've been weighing are founder, head of support, CTO, and lead engineer. So far my best replies have come from technical founders who recognize the pattern in their own week, but I haven't tested the support-lead pitch at all. Curious whether your instinct says to lead with one of those four or write parallel versions.
Whenever you have time. No rush. Razvan
Sent you a note by email. Main thing is choosing the first buyer segment before EzLogs gets pulled into four different positioning stories.
The person-shaped pitch works on VPs who've been that translator themselves. If they've lived it, 'I used to be this person on every team I joined' closes the gap faster than any ROI slide. The business case matters when the buyer is buying for others' pain, not their own. Start person-shaped and have the numbers ready for the second conversation.
In every deal I've seen close for tools like this, it's the eng lead who champions it but the person one level up who signs off - VP of Product or CTO who's tired of the translation tax showing up in missed sprints. The support lead has the pain but usually not the budget authority. Start with eng lead to build the use case, then get them to pull in their manager for the business case conversation. The translator doesn't sign the PO but they absolutely control the internal pitch. Have you had any real conversations with the eng side yet?
That two-step framing is the part I keep missing. I've been writing the pitch like it's one conversation, and it really isn't. Eng lead champions, VP or CTO signs off because they're the one watching missed sprints. Support has the pain but no budget. That maps to what I'm seeing in early replies.
On the eng side: honestly not deep enough yet. About thirty cold emails to Rails eng leads in the last week, a few public threads like this one, four or five real back-and-forths. They get it fast, but nobody has pulled their manager in yet. That's exactly the gap you're pointing at.
One thing I keep noticing: the eng leads who recognize themselves in the post don't quote the productivity line. They quote "I was the translator." So the internal pitch they'd make to a VP might end up being person-shaped, not productivity-shaped. Have you seen that work, or does it tend to lose to the harder business case?
The correlation problem you described is real and undervalued. But there's a complementary class of failure that never reaches your logs in the first place — the silent client-side ones. A button that does nothing because a click handler was wired to a DOM element that got removed. An API returning 200 with an empty payload the frontend quietly swallows. A multi-step flow where the server logged a successful request but the user's next action never fires. From Sidekiq and your app logs' perspective, nothing went wrong, so there's nothing for the translator to work with. These surface as conversion drops or churn weeks later. Your tool solves "hard to translate" failures; this other tier is "never emitted in the first place."
this is the cleanest version of the gap I've been failing to articulate.
"hard to translate" vs "never emitted in the first place" is right. the agent watches what crossed the wire on the server side. ruby for rails, javascript for next.js, same shape. if nothing crossed the wire, neither side knows the user was even in the room. silent client-side failures, dead clicks, empty payloads the frontend swallowed quietly. all of that is invisible to what I'm building.
the honest answer is that's a different product. dom-state and client-side flow capture is what session replay tools and frontend error tools cover. the part I'm still working out is whether the right play is to stay in the backend lane and integrate with whatever the team already uses on the frontend, stitching by correlation id, or whether there's a thinner browser-side agent worth shipping that just emits "user did X but no request fired" events.
how do you think about that boundary in your own work? when a team is debugging "users dropping out of a flow," do you see them reach for backend logs first, frontend tools first, or some session-replay thing that ties them together?
The translator tax is one of the most undervalued costs in any engineering org. The 20-minute interruption is the visible part — the context rebuild after is the 40 minutes nobody tracks. The question I'd push on: are you selling to engineering leads (who see the productivity cost) or support leads (who see resolution time)? Those are completely different buyers with different budgets and different ways of saying yes. The translator themselves rarely controls the budget.
the 40 minutes nobody tracks. that's the part I keep losing arguments about internally because it doesn't show up anywhere. people see the 20 minute slack thread. nobody sees the deploy that got delayed because the senior engineer couldn't get back into the problem they were in before.
the buyer split is the question I've been stuck on for weeks. eng lead pitch sounds like "your senior people stop getting interrupted." support lead pitch sounds like "your team answers without waiting on engineering." same gem. completely different headline. probably different price.
right now I'm leaning eng lead first, partly because the pain is sharper and partly because they're the ones reading ruby blogs at 11pm. but you nailed it, the translator doesn't sign the PO. the person watching them burn out does.
if you've seen a tool like this get bought before, what side of the org wrote the check? I keep guessing and I'd rather know.
From what I've seen, the check comes from whoever got embarrassed most recently. Practically that usually means engineering leadership. They're the ones who had to explain a production incident or a delayed deploy to someone above them and couldn't fully account for the 40 minutes you're describing. Support buys when they've been told 'build a process' one too many times. Eng buys when the cost became someone's problem in a QBR. Your instinct to go eng lead first tracks. They already know the hidden cost even if they haven't named it.
This comment was deleted a month ago.
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.