We weren’t slow at fixing bugs —we just didn’t understand them
Most bug reports are useless. So I built this.
I used to think building an AI customer support chatbot would help reduce bugs. The idea was simple: if users could report issues easily through chat, we wouldn’t miss anything.
And at first, it actually worked. We started receiving bug reports faster, fewer things slipped through the cracks, and it felt like real progress.
But after a while, a different problem showed up.
Most of the reports… weren’t very useful. Users would say things like “it’s broken”, “button not working”, or “app doesn’t run”. We knew something was wrong, but we had no idea what they did before, where it happened, or how to reproduce it.
I remember one time our team spent almost 2 hours just trying to understand a single bug before we could even start fixing it. And it wasn’t a rare case.
Even worse, many issues were only reported after users got frustrated and left. By the time we saw the problem, the damage was already done.
That’s when it clicked for me. The problem wasn’t that we were slow at fixing bugs. We just didn’t understand them early enough.
Once I saw that, everything changed. We were already working with AI — chatbots, context handling, trying to understand user intent. So I started wondering: what if we applied the same idea to bugs?
Instead of waiting for users to describe issues (poorly), what if we could capture what actually happened?
So I built a small internal tool. It watches for errors in real time, captures the context around them, and turns that into something developers can actually act on — not just logs, but something closer to a ready-to-fix ticket.
The first time we ran it, it caught bugs before users even noticed them. More importantly, when a bug happened, we didn’t have to guess anymore. We knew what happened.
That’s how Flashlog started.
We’re still building and testing it with early users, improving it based on real-world feedback.
If you’re dealing with similar issues, you can try it here and let me know what you think.
Any feedback — brutal or not — is super valuable at this stage. If you’re open to it, you can try Flashlog here.
This resonates a lot.
We saw a very similar pattern on the user side. People assume the problem is fixing speed, but most of the time it’s just lack of clarity on what actually happened.
Bug reports like “it’s broken” are basically useless without context, and by the time they come in, the user is already frustrated or gone.
What you’re doing with FlashLog makes sense, capturing the issue with full context at the moment it happens instead of relying on users to explain it later.
We’ve been thinking about a similar gap with Flidget, but around churn instead of bugs. Teams have analytics and dashboards, but still don’t know why users leave or where things break in the real flow.
Feels like both are solving the same core problem from different sides, replacing guesswork with real signals at the exact moment something goes wrong.
Curious how you’re thinking about handling edge cases where something looks like a bug but is actually expected behavior?
That’s something we’ve been thinking about quite a bit.
A lot of “errors” are actually expected behavior like validation failures, permission checks, or users submitting invalid input. If you treat all of those as bugs, the signal gets noisy very quickly.
We try to handle this by adding a classification layer on top of the raw events. Instead of just logging every failure, we look at the context (request/response patterns, status codes, user actions) to distinguish between actual issues and expected outcomes.
For example, if a form submission fails due to invalid input, that’s typically treated as user behavior rather than a product bug, so it doesn’t surface as a bug ticket.
It’s still an evolving area, but the goal is to reduce noise and help teams focus on things that actually need fixing.
If you’re curious, there’s a quick demo here: https://flashlog.app — would love to hear how it compares to what you’re using.
Interesting that it wasn’t quantization but a YaRN parsing quirk (mscale all dim) across stacks like transformers and llama.cpp.
Makes you wonder how many benchmarks were unknowingly affected.
love the idea an product. what technology is your interface and this tool built on. would be great if you could share some technical details as well
Thanks a lot — really appreciate it.
Our interface is built with React + TypeScript (dashboard on Next.js), and the tracking script/SDK is built in TypeScript and bundled for browser usage (UMD/ES) via CDN.
On the backend, we run Node.js (NestJS) with PostgreSQL for issue/event data and Redis-based workers for async processing.
At a high level, the SDK captures client-side runtime signals (network/API failures, JS errors, and WebSocket issues), then sends structured events to our backend where we enrich, group, and turn them into actionable issue reports/tickets.
Happy to share a deeper architecture walkthrough as well if helpful.
Really appreciate all the thoughtful comments here — this has been super helpful for us.
We’re still building and refining Flashlog based on real-world usage, so if you’re dealing with similar debugging issues, feel free to give it a try here:
https://flashlog.app
Would love to hear any feedback or edge cases you run into, especially from real production use.
This is painfully accurate. Half of “debugging” is really just archaeology with incomplete clues.
Yeah, exactly — once you have the sequence, everything clicks.
We had the same realization. If you’re still dealing with debugging issues, feel free to try Flashlog — would love your thoughts.
users report what they experience, not what broke. 'it stopped working' is always accurate from their side - they just don't have the stack trace. rebuilding from symptom to root cause is the actual hard problem here.
Yeah, that’s exactly it.
Users report the symptom, not the cause and from their perspective, “it stopped working” is completely accurate.
The hard part is going from that symptom back to what actually broke.
That’s why we’ve been focusing less on collecting better descriptions, and more on capturing what actually happened around that moment.
If you already have the sequence of actions, the failing request, and the environment, you don’t need the user to explain anything you can work backwards from the real event instead of guessing from the symptom.
If you’re curious, there’s a quick demo here: https://flashlog.app — would love to hear how it compares to what you’re using.
yeah, that shift is underrated. spent months building better intake forms before realizing we were solving the wrong problem. the moment you have the sequence, the user description becomes decoration.
users report what they experience, not what broke. 'it stopped working' is always accurate from their side - they just don't have the stack trace. rebuilding from symptom to root cause is the actual hard problem here.
None that I can think of, but keep up the great work
Appreciate that, thanks a lot 🙏
Still early for us, so feedback like this really helps shape what we build next.
The 2 hours spent understanding a single bug before touching the fix is the invisible tax nobody puts in their engineering estimates. It's not in the sprint planning, it's not in the velocity metrics, it shows up as 'why did this take so long' at the retrospective. The reframe from slow fixing to poor understanding is the right diagnosis the bottleneck was never the engineering capacity, it was the information gap between what users experience and what developers see. Capturing context at the moment of failure instead of relying on a frustrated user to describe it accurately is a completely different class of signal. Curious whether Flashlog distinguishes between errors that users notice and errors that happen silently in the background because in my experience the silent ones are often the most damaging.
You're describing exactly the problem I ran into.
Most of the time wasn't spent fixing bugs, it was trying to reconstruct what actually happened from incomplete signals logs, vague user reports, or just guessing.
That’s why Flashlog focuses on capturing context at the moment things break, instead of relying on reproduction later.
On your question about visible vs silent errors:
We try to treat them differently.
Visible errors (like crashes or blocked UI) are easier to catch because users naturally surface them.
Silent errors are trickier and often more damaging, like failed API calls, broken state updates, or events not firing. Users don’t report them, but they can quietly degrade the product.
Flashlog surfaces both, but the key difference is:
we don’t rely only on error logs. We tie errors back to user sessions, so even silent failures can be seen in context of what the user was actually doing.
Still early, but the goal is exactly what you described reducing the "understanding tax" as much as possible.
If you’re curious, there’s a quick demo here: https://flashlog.app — would love to hear how it compares to what you’re using.
The classification layer makes total sense. Without it you'd just be drowning in noise and that defeats the whole point.
The line between user behavior and actual bugs is the right one to draw. Curious though, how does it handle cases where the same action is a bug for one user type but expected for another?
We're seeing something similar with Flidget but on the churn side. Users leave for all kinds of reasons, price, missing feature, confusion, but without capturing what's actually happening at the moment they decide to leave, it all looks the same in your analytics. So we just intercept that moment and let them tell you directly why they're going.
Honestly feels like FlashLog and Flidget are going after the same root problem from different angles. Would be interesting to see both running on the same product.
Session context changes the whole game here. An API failure on its own tells you almost nothing, same failure with the user session wrapped around it tells you everything. What they clicked, what state the app was in, what they were trying to do. You stop guessing and start actually seeing it. The traditional logging approach has always had this gap, you get the what but never the why. Sounds like that’s exactly the gap you’re closing. How intensive is the setup process right now for a new user? Curious whether it requires significant instrumentation upfront or whether it starts surfacing useful data quickly.
Good question.
Right now the setup is pretty minimal.
You basically create a project, copy a small script, and add it to your app (similar to how you’d install something like analytics). There’s no required upfront instrumentation to start getting value.
Once it’s in place, Flashlog starts capturing sessions and errors automatically as users interact with your app, so you can see issues in real context without extra setup.
You can go deeper later with custom tracking if needed, but the goal is that you get useful signals almost immediately after install.
We also send summaries (daily/weekly) so you don’t have to constantly check the dashboard.
Copy a script and get useful signals immediately is the right onboarding philosophy for a developer tool. The moment someone has to instrument their entire codebase before seeing any value is the moment most of them close the tab and never come back. The daily and weekly summaries are smarter than they might seem on the surface too dashboards require intent to check, summaries require nothing. You’re removing the activation cost of remembering to care about errors. Curious what the summaries actually look like are they showing raw error counts or are they surfacing the sessions worth actually looking at?
That’s exactly how we think about it the summary shouldn’t feel like a report, it should feel like a quick decision layer.
So instead of focusing on raw counts, we try to highlight what actually matters right away.
For example, the summary surfaces:
- how many critical / high issues occurred
- the top issues ranked by impact (e.g. number of users affected)
- the top pages or flows where bugs are happening most
So at a glance, you can answer:
- what broke today?
- how serious is it?
- where is it happening most?
The idea is that you shouldn’t need to open the dashboard just to understand the situation.
If something stands out, then you dive deeper into the specific session or issue.
The three questions framing is the right way to think about it what broke, how serious, where. That’s the decision layer not a report. Most dashboards answer a fourth question nobody asked which is ‘here is everything that happened’ and leave the first three as exercises for the reader. Ranking by users affected rather than frequency is the call that separates useful from noise too. A bug that hit one user 50 times is a very different problem than a bug that hit 50 users once. Same count, completely different urgency. The not needing to open the dashboard part is the real product promise the summary earns its place if it makes the dashboard optional rather than mandatory.
Vague bug reports like it is broken waste so much engineering time because you end up playing detective instead of actually coding a fix. Most developers do not realize that capturing the specific state of the local storage or redacting sensitive data automatically can be the difference between a ten minute fix and a two hour investigation. Does your tool offer a way to replay the user session visually so the team can see the exact click path leading to the crash?
Yeah, we do.
For each issue, we try to capture enough context so you don’t have to reconstruct what happened later.
That includes the exact URL/screen where the bug occurred, the sequence of user actions leading up to it, and the related network requests (like failed APIs).
We also provide session replay, so instead of guessing from logs, you can actually see the click path that led to the issue.
The goal is exactly what you described avoiding the “playing detective” part and getting as close as possible to a complete picture when you open a ticket.
If you’re curious, you can check it out here: https://flashlog.app — happy to hear any feedback.
It is great that you are including session replay alongside network requests because seeing the visual context usually reveals the UI edge cases that logs alone tend to miss.
That transition from "guessing" to "seeing" is exactly what turns a frustrated developer into a productive one since it removes the friction of trying to replicate weird state issues manually.
In my work with high-tier PR and media placement for tech brands we focus heavily on these kinds of "time-to-value" metrics because they make for such a compelling authority story for major news outlets.
Do you have a way to automatically redact sensitive user data from the session replays so teams don't have to worry about privacy compliance while they debug?
Totally agree — the “seeing vs guessing” shift has been huge for us as well.
On the privacy side, this was something we were very careful about from the beginning.
We don’t record everything by default. There’s a filtering layer that removes sensitive user data before it ever gets logged. On top of that, we use a classification step to detect potentially sensitive fields and avoid capturing or tracking them altogether.
The goal is to give enough context to debug effectively, without exposing anything users wouldn’t expect to be recorded.
Privacy-first by design is the only way to build in this space now. That filtering layer you mentioned isn't just a feature—it's a massive trust asset.
In the tech media world right now, there’s a huge appetite for stories about 'Privacy-Compliant Debugging.' Most tools struggle with this balance, and if you've truly cracked the 'context without exposure' puzzle, you’ve got a very strong angle for a technical deep dive on sites like VentureBeat or Wired.
Definitely keep me posted as you scale. This is the kind of 'Responsible AI/Tech' story that journalists love to champion.
Appreciate this a lot — especially the point about privacy being a trust layer, not just a feature.
This is something we’ve been very intentional about while building Flashlog, and we’re still learning a lot as we go.
We’ll keep sharing what we discover as things evolve.
Would also love to hear how others here are approaching this — feels like there’s still no clear “best practice” yet.
The fact that there's no clear 'best practice' yet is exactly why your journey is so valuable. Whoever defines those practices first becomes the natural authority in the space.
That’s exactly how we approach PR—taking those real-world 'discoveries' you're making and turning them into the industry standard through media. Looking forward to seeing how Flashlog evolves. Keep building, Dylan!
Appreciate this a lot — really means a lot.
We’re still figuring things out as we go, but that’s exactly what makes it interesting. Will keep sharing what we learn as we build Flashlog.
Thanks again for the encouragement 🙏
The 2-hour debugging story is the right problem to name. But there's a layer underneath it worth separating.
What you're solving right now is context capture: turning "it's broken" into a reproducible event trace. That's genuinely hard and Flashlog seems to have a solid approach to it.
The harder problem, which tends to show up a few months in, is when the error logs look clean but the product is still failing users. No exceptions. No 500s. The AI responded. It just responded to something subtly different from what the user meant, and the disconnect only shows up in churn data six weeks later.
Standard observability tools catch Layer 1 failures, the ones with stack traces. What they miss is Layer 2: the model completed a valid call, returned a well-formed response, but the interpretation step was off. That failure mode has no error log because nothing technically failed.
The thing I'd be curious about with Flashlog is whether you're planning to capture the AI reasoning path alongside the application error, or just the application state. If you're only logging the exception context, you'll catch the bugs that throw. The more subtle failures, where the chatbot "understood" the report but misclassified it, leave no trace in a standard error log.
That gap tends to become visible when your error categorization starts drifting from reality. Worth building the inference trace layer early, before the volume makes it expensive to add retroactively.
This is a great way to frame it.
Right now, Flashlog is still very much focused on what you described as Layer 1 capturing concrete failures like JS errors, failed API calls, or broken flows, and tying them back to real user sessions so they’re actually debuggable.
But we’re starting to run into exactly the Layer 2 problem you mentioned, where everything “works” technically, but the outcome is still wrong from the user’s perspective.
What we’re exploring next is moving beyond just error capture into session-level understanding looking at sequences of events and user actions to detect when something goes off track, even if no exception is thrown.
That likely means capturing more of the decision layer (especially for AI-driven flows), not just application state.
Still early for us, but I agree this is where things get much more interesting and also much harder
Good!