About Recon

Why this exists

I'm an engineer. For years, I was the guy everyone pinged in Slack.

CS would get a ticket from a customer saying "our reports aren't loading." The answer wasn't in the knowledge base, because let's be honest, those docs are never up to date. The real answer was buried somewhere across four different systems: a config change in the codebase, an error spike in Sentry, a related ticket in Linear that engineering was already tracking, and maybe an architecture doc in Notion that explained why the system works that way.

So the CS person would ping me. I'd drop what I was doing, spend 30-45 minutes digging, and paste the answer back. Then I'd try to remember what I was working on before I got interrupted.

This happened multiple times a week. Multiply it across a growing customer base and it becomes a real bottleneck. The CS team is waiting. The engineers are context-switching. Nobody's happy. I built Recon because I got tired of being that bottleneck.

What Recon actually does

Recon is like giving your non-technical team their own engineer.

It connects to 11 tools your company already uses: your database (Postgres, Supabase), your codebase (GitHub), your tickets (Linear, Jira), your docs (Notion, Confluence), your support platform (Intercom), your error tracking (Sentry), your billing (Stripe), and your CRM (HubSpot).

Your CS lead asks a question in Slack: "Why did this customer's usage drop?" Recon does the initial investigation. It checks if there's an error spike in Sentry, looks at what's actually happening in the code, cross-references open tickets, and comes back with the root cause. It writes and runs Python in an isolated sandbox to do real computation, not just keyword matching.

It can also suggest a response to the customer, create a ticket in Linear or Jira with full context, or generate reports using live production data. No SQL. No code. No waiting on engineering. Just plain English in Slack.

Beyond one-off questions, Recon runs recurring missions that monitor your accounts on a schedule. It builds a knowledge base over time, learning your customers, patterns, and product behavior. When it finds something actionable, it creates an advisory with a suggested next step. You approve or reject with one click. Over weeks, it compounds what it knows, finding patterns that no single investigation would catch.

Integrations

Live now

PostgresSupabaseGitHubNotionLinearJiraConfluenceIntercomHubSpotSentryStripeZendeskSlack

Coming soon

AsanaSnowflakeBigQueryConfluentQuipPostHogGoogle Analytics

What we believe

Knowledge bases are always out of date

The most current answers live in the code, the database, and the tickets your team is already tracking. Recon goes to the source instead of relying on docs that were last updated three months ago.

Support shouldn't be a waiting game

When a customer has an issue, the CS person shouldn't have to wait hours for an engineer to investigate. They should be able to get the answer themselves, in minutes.

Investigation is the bottleneck

There are great tools for managing tickets and great tools for resolving them. But nobody was solving the investigation layer: the 30-60 minutes of cross-system digging that happens between "customer has an issue" and "we know what's wrong."

Security is non-negotiable

Databases and code are strictly read-only. Every query is logged and auditable. Credentials are AES-256 encrypted and injected ephemerally. Each investigation runs in its own isolated Firecracker microVM.

What's next

Missions, knowledge, and advisories are live today. The next frontier is depth: more integrations, richer pattern detection, and tighter feedback loops so Recon gets sharper with every rejection and approval.

The vision has not changed: Monitor, Investigate, Act, Communicate. One system, not four separate workflows. We are building toward the point where your CS lead walks into Slack Monday morning and the work is already done.

Who's behind this

Recon is built by Pratik, an engineer and AI practitioner based in the Bay Area. He spent years watching the same problem play out at SaaS companies: non-technical teams stuck waiting on engineering for answers that already existed in the data.

Building in public. Follow the journey on X at @chaibytesai.