Chime — an NPS feedback analysis tool for customer success teams

Chime clusters NPS survey responses into themes by promoter, passive, and detractor segment using an LLM, then outputs a benchmarked score and a prioritized action list instead of a raw spreadsheet.

@swabhig

getchimed.sitevisit ↗

Chime — an NPS feedback analysis tool for customer success teams

watch the video↗

process.log7 fields

toolsClaude (Sonnet)Vercel v0Claude DesignSupabaseAnthropic API

iterationsMany attempts

dozens of prompts across the UI, auth, and export systems

time2 weekends

%_ai92

me 8

ai 92

self-reported · generously rounded

# how_it_was_made

questions0

no questions yet

ask how it was made — the dead-ends are usually the good part

ask about the process…sign in

~/slopfolio··

Chime is built for customer success teams who collect NPS feedback but don't have time to read every response. I designed the analysis approach myself, based on Rahul Vohra's product-market fit framework from Superhuman: segment respondents by score, then analyze each group separately instead of averaging everyone together. Claude wrote the clustering prompts, the Supabase schema, the authentication flow, and every API route; I made the product calls — what data model to use, which OAuth scope tradeoffs to accept, what the exports should actually contain. Vercel v0 handled initial UI generation, and Claude Design did a full visual redesign later in the build, which Claude then wired back into the working backend logic. Export options ended up as a PDF summary, a Google Sheet, a CSV, and a copy-paste Slack summary.

// best_dead_end

I originally wanted the Google Sheets export to write six separate tabs. Building that required a Google OAuth scope that Google classifies as "sensitive," which caps unverified apps at around 100 total users. I dropped it for a single combined sheet using a narrower, unrestricted scope instead — less clean structurally, but no user cap and no verification review needed.

# prompting_approach

I worked feature by feature rather than describing the whole app upfront, and I always tested the actual result before moving on rather than trusting a description of what should have happened. Bugs came up more than once from AI-generated code quietly reverting a previous fix, so re-checking known-working behavior after any regeneration became a habit, not a one-off step.