Dingus

I’m Leon, founder of Dingus - an AI-powered debugging assistant for dev teams using Kubernetes, Loki, and Prometheus. We help teams squash production bugs by automatically analysing logs and suggesting fixes before things go sideways.

But as any indie dev knows, building is only half the battle.

🔍 Finding Your ICP Is Slow (and Kinda Painful)

Everyone says, “talk to users” - but which users? And where are they?

Figuring out our ideal customer profile has been one of the slowest parts of this journey. We’re targeting SREs, lead engineers, and devs managing production infra - people who are already feeling the pain of bad observability. But getting in front of them has required more than just posting into the void.

🛠️ Bespoke > Blast: Using Apollo to Search, Not Spam

I started using Apollo.io, not to run outbound sequences, but to manually explore the right kinds of companies and roles. I’m skipping the automation entirely.

Instead, I dig into:

• Who’s likely running K8s + Loki/Prometheus?

• Which companies are mid-stage and don’t have full SRE teams?

• Where might a tool like Dingus actually save real engineering time?

I treat every message like a mini pitch tailored to their situation. It takes longer, but it feels way more human - and people love it.

💬 What’s Worked for You?

If you’re building a product for a niche user base, I’d love to know:

• Where do you go to find real, high-intent users?

• What outreach channels feel authentic and not spammy?

• Have you had any success with dev-focused platforms like GitHub, Reddit, or Stack Overflow?

Always keen to swap ideas, tools, and war stories on early traction.

— Leon
🐞 www.dingusai.dev

🔍 Getting Customer Discovery Right (Reddit has been 🔥)

I’ve been posting in places like r/ycombinator and r/devops, asking real devs and founders when they actually start caring about observability - trying to find out what triggers that "okay, we need logs and alerts now" moment.

It’s been super helpful for getting honest insights and setting up a few early calls with teams that feel the pain. If you’re struggling with outreach, I highly recommend just starting authentic discussions where your audience already hangs out.

🔧 Integrations Are the Make-or-Break Moment

I'm now learning that integrations are everything.

A debugging tool isn’t very useful if it can’t talk to your stack. That means deep hooks into:

• Loki for logs

• Prometheus for metrics

• Kubernetes APIs for cluster context

Every dev I’ve spoken to has a slightly different infra setup, which makes it clear: if we want adoption, we need to meet devs where they are, not force a new stack on them.

🧭 Still Figuring Out the Right Distribution

This is a big one.

We’re currently deciding:

• Do we go open-source to build community and trust?

• Package it as a SaaS app for quick onboarding?

• Offer an Electron desktop app for local debugging?

• Or maybe… all three?

Each one has tradeoffs in terms of trust, speed to value, and business model. If you’ve walked this line before, I’d love your input here.

What's Next?

I’ll be shipping some updated Loki/K8s integrations, making setup smoother, and probably leaning harder into open source + community-led distribution.

If you’ve built something dev-facing, I’d love to hear:

• How did you approach early integrations?

• What distribution path worked best for you?

• Any lessons learned from doing customer discovery in the devtools space?

Thanks for reading - and if you’re into AI, infra, or debugging tools, hit me up! Always down to swap notes 👇

- Leon
🐞 www.dingusai.dev
🔗 github.com/dingus-technology/chat-with-logs

Breakthrough: Chat with Logs is a Game-Changer for Debugging

A few months ago, I set out to build an AI-powered debugging assistant that could take the pain out of production issues. The goal was simple: speed up incident resolution by automating the tedious process of searching through logs and diagnosing problems. Now, after weeks of testing and iteration, I’m seeing incredible results - Chat with Logs is catching and fixing bugs faster than I ever could manually.

The Pain of Debugging - Before AI Helped

Like many engineers, I’ve spent countless hours sifting through logs, piecing together cryptic error messages, and chasing down issues that only appear at scale in production. The process was:

1. Find the Logs - Dig through Loki, Grafana, Prometheus, Kubernetes pods, grep through files, or query dashboards just to see what’s going on.

2. Identify the Root Cause - Parse through endless lines of logs, searching for the critical failure.

3. Look for a Fix - Google/GPT error messages, check internal docs, and try to recall past incidents that were similar.

It was slow, frustrating, and prone to human error - especially under pressure when production is down.

Chat with Logs: AI-Powered Debugging That Just Works

Enter Chat with Logs - an AI-powered assistant that reads and understands your logs in real time, surfaces key issues, and suggests actionable fixes. With Kubernetes and Loki integration, it plugs directly into your system and acts as a first responder for incidents.

Here's how it works:

✅ Automatic Log Analysis - It scans through your logs, picks up anomalies, and extracts the most relevant information.
✅ Instant Root Cause Detection - Instead of manually searching, you get a direct answer: “Here’s what’s broken, and why.”
✅ AI-Suggested Fixes - No more frantic Googling. Chat with Logs suggests potential resolutions based on learned patterns and previous incidents.

Seeing It in Action

Last week, a production issue popped up - CPU spikes, failing API calls, and some cryptic errors in Loki. Normally, I’d spend at least 30–45 minutes tracking it down. But with Chat with Logs:

🚀 The AI instantly surfaced the key log lines causing the issue.
🚀 It diagnosed the problem as an out-of-memory error due to an overloaded pod.
🚀 It suggested a fix: increase resource limits in my Kubernetes deployment.

Total time to resolution: less than 5 minutes. If I had done it manually, I’d still be scrolling through logs.

Dingus: The Bigger Picture

Chat with Logs is just one piece of what we’re building at Dingus (@www.dingusai.dev). Our vision is to redefine debugging with AI - turning logs and monitoring data into actionable insights instead of just noise. Whether it’s logs, metrics, or tracing, we’re making AI-powered tools that give engineers superpowers.

Want to Try It?

Chat with Logs is open source! If you’re tired of the manual debugging grind get in touch with me leon@dingusai.dev or checkout the site www.dingusai.dev.

We are currently rolling out the software to beta users so drop me a message fast if you're interested! 🚀🐞

I’ve always felt the pain of deployments failing at work—those moments when the lights go out on production, and you’re scrambling to figure out what went wrong. It’s a familiar scenario: sometimes, you don’t even know there’s an issue until it’s too late, and when you do, pinpointing the exact bug can be like searching for a needle in a haystack. Not to mention the stress of tech when its down!

The Problem

In my day-to-day work, I faced three recurring challenges:

• Undetected Issues: Often, bugs lurk in the background. Without a reliable alert system, you might never even know that something is wrong until users start complaining.

• Time-Consuming Diagnosis: Even when you’re aware of a problem, tracking down the root cause can be a painstaking process.

• Repetitive Resolutions: More often than not, the steps to resolve these issues follow a predictable pattern. Yet, repeating this process manually is not only inefficient but also error-prone.

I realised that these challenges were not unique to me—many developers face them daily. It became clear: there had to be a better way.

The Idea

I started thinking, "What if I could build an AI tool that automates this entire process?" The idea was simple: follow the same steps that I use every time I encounter a bug, but do it faster and more reliably. This tool would need to:

1. Detect Bugs: Identify issues before they escalate.

2. Raise Alerts: Inform the right people or systems about the problem.

3. Suggest Fixes: Provide potential fixes based on learned patterns and previous resolutions.

Building the MVP

I rolled up my sleeves and got to work. The first version of the tool—a minimal viable product—was designed to mimic my debugging process. And it worked! In a real-world scenario, the MVP:

• Caught a Bug: It detected an issue before I even noticed something was wrong.

• Raised the Issue: Automatically created an alert, ensuring that the problem was on everyone’s radar.

• Suggested a Fix: Offered a potential fix in record time—faster than I could ever manually debug and resolve the issue.

Seeing this process in action was a game-changer. The MVP proved that the repetitive steps in debugging could be automated with AI, saving time and reducing downtime significantly.

Looking Ahead

This is just the beginning. I’m excited about the future as I work on making the tool production-ready. There’s a lot more to do:

• Enhancements & Integrations: I plan to integrate the tool with a broader range of systems and workflows.

• Community Feedback: I’m eager to collaborate with fellow developers and get your thoughts, ideas, and even bug reports to make this tool even better.

• Open Source: I believe in the power of community. If you’re interested in the project, let’s connect—message me for the GitHub link!

I hope my story resonates with you. Let’s embrace the future of AI-powered debugging together and make our code, and our lives, a lot smoother.

Here’s to faster resolutions, fewer headaches, and a more efficient development process!

Here's to www.dingusai.dev 🐞