Building ICK: From Personal Frustration to Product Signal Engine

I have a running Notes doc of app crashes, unsubscribable subscriptions, and autoplaying videos. I kept adding to it because the frustration was real — but it was going nowhere.

That's the actual problem. Product complaints are everywhere: Twitter, Reddit, support tickets, 1-star reviews. But they're fragmented, unstructured, and invisible to anyone who could do something with them. A designer tweets about a broken file-sharing flow. A developer posts the same complaint on Reddit three months later. No one connects the dots. The signal is there; the infrastructure to capture it isn't.

ICK is that infrastructure.

What I Built

Users submit product frustrations in plain language. Each submission is analyzed by Google Gemini to extract structured signal:

• Sentiment — gross / no way / acceptable
• Severity — 1–10
• Category — tech, work, dating, transport, and more
• Opportunity score — 1–10, reflecting market potential
• Tags and reasoning — structured metadata with a short explanation of why this matters

The Insights dashboard renders all submissions on an interactive canvas with three views: gravity (high-severity complaints pull toward center), cluster (grouped by sentiment), and timeline. Builders filter by sentiment, category, and tags to spot recurring patterns — the places where frustration concentrates and solutions don't yet exist.

Why Frustrations, Not Feature Requests?

Feature requests are wishes. Frustrations are evidence.

When someone complains about a product, they're telling you three things at once: the category matters to them, the current solution has failed them, and they care enough to say something. That's denser signal than any survey. I built ICK around that insight — not "what would you want?" but "what's already making you angry?"

The outputs surprised me. "Scheduling sucks" didn't point to another calendar app — it pointed to async coordination. "Password managers are annoying" wasn't about UX polish — it was about invisible security anxiety. Complaints are more honest than ideas, and more contextual. ICK makes that mapping explicit.

A Decision I Pushed Back On

My initial instinct was to give users more control over how their frustrations were categorized — a kind of tagging marketplace where submitters could label their own icks. It seemed like it would produce richer data.

It wouldn't. Manual tagging creates inconsistency, introduces user bias, and adds friction at exactly the moment you need the opposite. The insight that changed my thinking: the frustration itself is the data. The job of the product is to get out of the way and let AI do the structuring. Removing manual categorization entirely made the submission flow faster and the output more reliable.

Technical Decisions

I optimized for iteration speed over premature scale:

• Frontend: Next.js 15 + React 19 + TypeScript
• Database: PostgreSQL + Prisma
• AI: Google Gemini for analysis, with a local keyword fallback when the API is unavailable
• UI: Radix UI + Tailwind + Lucide icons

The architecture is deliberately lean. No complex taxonomies, no manual tagging — the AI handles structure so the product can stay focused on capture and discovery.

What's Next

A browser extension is in development so users can vent from any page in one click — capturing frustration in context, at the moment it happens. Longer term: predictive opportunity scoring and builder matching, so the people experiencing a pain point and the people who could solve it can find each other.

ICK isn't a replacement for product intuition. It's a systematic way to see what people are already complaining about — before you spend six months building the wrong thing.