How I Vibe-Coded a Customer Success Hub Using StackOne's AI Native Integration Platform
Table of Contents
The CS-Hub is an internal customer success dashboard I vibe-coded using StackOne’s AI native integration platform, pulling live data from HubSpot, Pylon, PostHog, Databricks, and Fireflies into one customer 360 view.
What is vibe coding?
Vibe coding is building software by talking to an LLM in plain English instead of writing every line by hand. You describe what you want, the model writes and edits the code, you test, iterate, and ship. The skill that matters is product vision, not code syntax. The term was coined by Andrej Karpathy in February 2025.
Here at StackOne, we’ve consistently grown our customer pool. More recently, we’ve built out a product-led growth (PLG) motion.
What does this mean for a lean CS team with a wide-ranging tech stack?
Lots of customers, lots of data, lots of tabs and, ultimately, a bit of a headache.
HubSpot as the CRM. Pylon for support tickets. PostHog and Databricks for product usage. Fireflies for call notes and transcripts. Gmail and Slack for context.
Before any account review I was doing fifteen or twenty minutes of tab archaeology just to answer the question: “what’s actually going on with this customer right now?”
The irony was hard to ignore. StackOne exists to solve exactly this problem for our customers, connecting enterprise systems so teams can stop hopping between tools.
So I built the CS-Hub: an internal dashboard that surfaces all of that context in one place, for every customer we have set up on StackOne.
How? The integration work was essentially out of the box. StackOne has 250+ SaaS connectors that can be accessed by AI agents via MCP, A2A, and SDK, or by software via RPC. Each comes with the agent actions I needed to pull the data. I got to a first working version over a couple of evenings.
Why SLG-Built CS Tooling Breaks at PLG Scale
SLG-built CS tooling was designed for a small portfolio of large accounts: QBRs, shared slides, health scores, a CSM per logo. It works when you have 10-20 customers and a CS team large enough to give each one attention.
PLG breaks this model. You might have a hundred accounts at different stages: some self-serve customers you barely touch, others quietly expanding, others silently churning. The signal is there in product analytics, support queues, and call transcripts. But it’s scattered, and nobody has time to manually correlate multiple sources before drafting every email or telling leadership what’s going on.
The data problem is solvable. Connecting up to ten production systems for an internal tool is normally a real engineering project, unless you build on StackOne, where those connectors are production-tested and ready to go.
Inside the CS-Hub: A Customer 360 in One View
Every account in our PLG book gets a row in a single customer view, with the customer 360 detail one click away. Drilling into any one gives you:
- CRM data from HubSpot: contract value, renewal date, account owner, health score, recent notes
- Open support tickets from Pylon: age, status, and priority
- Product usage from PostHog: which customers are active, click volume, usage trends over the past 30 days, number of users per org
- Call history from Fireflies: summaries of recent conversations, flagged sentiment, open action items
- Connector health from Databricks: sync metrics and error rates from our infrastructure
- Context from Slack, Gmail, and Notion
There’s also a reconcile view for cross-referencing account data across sources, an activation view for tracking adoption stage by account, and a tasks layer for CS-owned action items.
The frontend is a static HTML shell with Tailwind v4 and Apache ECharts, plus a few React islands mounted via Vite for the interactive components. A Cloudflare Worker handles all data fetching against a D1 SQLite cache.
How StackOne Turned Five Integrations for the CS Hub into a Two-Evening Build
Connecting multiple data sources from scratch means OAuth flows for each, error handling, and a long tail of edge cases before you’ve written any product logic. For most CS leads, that’s where the project dies. The integration cost exceeds the motivation, and the spreadsheet stays.
StackOne handles that layer. Each source is a configured connector with an account ID. Calling HubSpot, Pylon, PostHog, or Fireflies from the worker is just an MCP tool call. Agent auth is pre-built, data arrives structured, and the only thing that changes between connectors is the account ID and the action name.
Databricks was the exception. It runs through a SQL warehouse query, which has been by far the most painful part of the build.
The MCP layer gave Claude Code direct tool access to live connector data. Through tool discovery, it found the right actions, combined data from multiple sources, and validated the responses in real time. I described the views I wanted and shipped features instead of debugging API quirks.
Using Claude to Summarize Customer Success Account Health and Draft Emails
With everything in one place, I could ask Claude to read the whole account in a single shot. That’s the second unlock from the consolidation work, and it’s where the dashboard turned from a viewer into something more useful.
The CS-Hub now runs agentic features on each account. The worker pulls the signals for one customer (request volume, click activity, ticket state, last call date), packages them into a single payload, and asks Claude to summarize the account’s current state and sentiment. The response comes back as structured JSON via Anthropic’s tool-use output format, gets written into the CS-Hub, and powers things like:
- Drafted emails based on each customer’s lifecycle stage
- Automated summary notes for the leadership team
- Per-account health write-ups
None of this would have been possible without StackOne’s MCP gateway. You can’t ask a model to assess account health when the data lives in six tabs. Once it lives in one place, the model can do it in seconds.
How the Vibe-Coded CS-Hub Improved Customer Success for PLG
The vibe-coded CS-Hub improved customer success for PLG in two ways:
- Fifteen minutes saved per account review. Context gathering used to mean tab-hopping across HubSpot, Pylon, PostHog, and Fireflies; now it’s one view. Adds up fast across a hundred accounts.
- Catching the customer in trouble before they send the cancel email. Product usage drops, unresolved tickets, and pricing concerns flagged on a call all land in one view, so you reach out first.
That’s the difference between a rescue conversation and a churn conversation.
What’s Next: Customer Success Automation
The longer arc is customer success automation: rules that watch the signal data and act when thresholds cross. A few examples queued up:
- Customers below a usage threshold 60 days before renewal get a check-in queued automatically
- Tickets older than 14 days trigger an escalation flag
- Expansion candidates get surfaced on a weekly cadence without anyone building the list
PLG retention at scale can’t run on human attention alone. Too many accounts, too many signals. The path is building intelligence that watches what you can’t monitor and surfaces what needs human judgment.
The infrastructure is already here. The CS-Hub is the first layer. The automation goes on top.
Vibe Coding + StackOne MCP Gateway for Non-Technical Builders
Ultimately, “vibe coding” plus StackOne’s MCP gateway has changed the game for non-technical-minded folks (like me) who have real pains to solve.
Put it this way: before I started building the CS-Hub, I had never written a line of code in my life. This is still the case.
If you want to build something similar, start with StackOne’s MCP gateway. Get free StackOne access or book a StackOne demo.
If you’re interested in building integrated internal tooling and want to learn more, reach out: charlie@stackone.com.