Got sick of tab-switching for support tickets, so I'm building Evidio
Hey everyone,
I’m Nikolai, and I'm currently building Evidio. I started this to scratch my own itch after realizing how much time was being wasted just trying to get context on simple customer support tickets.
When a user emails saying "I can't access this feature," we usually have to check Stripe to ensure their payment cleared, our database to check their plan tier, and PostHog to see what button they actually clicked before the error.
Manually lining up timestamps across 3 different dashboards was taking 15+ minutes per ticket.
Evidio is basically an internal tool to automate that. You paste in the user's email, and it pulls read-only data from your stack to generate a single chronological timeline (e.g., Invoice Failed > User Upgraded > Page Viewed > Permission Denied).
I'm currently building out the initial Stripe and PostHog connectors and opening up a waitlist for a private beta.
My goal right now is to figure out what other integrations are absolute must-haves for other founders. If you deal with this same support headache, I'd love to know what tools you constantly have to check to debug user issues.
Tab-switching frustration is one of the most reliable signals that a product will get used. If the pain is annoying enough to make someone build their own solution it is annoying enough to make other people pay to fix it. What does your current user look like - solo founders doing their own support or small teams with a dedicated support person?
That’s exactly the signal that pushed me to build this.
Right now it’s mostly solo founders and very small teams (2–10 people) who are still doing support themselves. They’re the ones constantly jumping between Stripe, PostHog, and their DB to understand what actually happened.
Interestingly, once a team has a dedicated support person, the pain is still there - but it’s a bit different:
they often don’t have direct access to all tools
or they rely on engineers to investigate issues
So instead of saving their own time, it becomes more about reducing back-and-forth between support and devs.
My current focus is on founders because:
the pain is immediate and obvious
they can adopt new tools faster
they’re already used to stitching things together manually
But I do think the longer-term opportunity is making this useful for support teams as well - especially as an internal tool that gives them more context without needing engineering every time.
Still early, so I’m trying to validate which group feels this pain the strongest.
This feels like something that could save a lot of time for teams dealing with scattered data across tools.
How are you thinking about getting this in front of your first users — more dev-focused communities or support teams?
Great question - this is actually what I’m trying to figure out right now.
My current thinking is to start with dev-focused teams and early-stage SaaS founders, since they’re usually the ones manually digging through logs and tools themselves (Stripe, PostHog, DB, etc.). They feel this pain immediately because there’s no dedicated support tooling yet.
For distribution, I’m exploring a few angles:
Talking directly to founders via communities like HN, Indie Hackers, etc.
Reaching out to teams already using tools like PostHog / Stripe and asking how they debug support issues today
Potentially building small integrations or templates around those tools to make onboarding feel very “native”
Longer term, I think support teams could be a big use case too - but they often already have workflows in place, so the entry point might be different (maybe via internal tooling or plugins).
Still early, so I’m trying to stay close to users and validate where the strongest pull is.
If you’ve seen teams solving this well (or struggling with it), I’d love to hear.
The instinct to start with dev-focused teams and early founders is right — they feel the pain the most because they don't have the budget or headcount to build proper support infrastructure, so they're stuck duct-taping Stripe dashboards and PostHog logs together.
The second angle you mentioned — reaching out to teams already using those tools and asking how they handle support debugging today — is probably your fastest path to learning what actually converts. Not pitching Evidio, just having 10 of those conversations will tell you more about positioning than months of testing landing page copy.
One thought on the integration angle: if you build even a lightweight Stripe or PostHog plugin that solves one specific annoying task, that becomes a distribution channel in itself. People share useful tools inside those ecosystems. It's not just onboarding — it's how they find you in the first place.
Hey Nikolai! The "15+ minutes per ticket switching between Stripe, PostHog, and the DB" really hit home. I'm researching metrics tools for solo SaaS founders right now. Curious — from the founders you've talked to, do most care more about seeing revenue metrics (MRR, churn) clearly, or about the operational pain (tab-switching, context loss)? Would love to learn from what you've discovered building Evidio.