Building in Public: AI-powered market intelligence tool to decode recurring business pain
Hey Product Hunt community!
I am Fernando, and I am building Market Pain Intelligence (MPI), an AI-powered tool that helps businesses identify and decode recurring market pain points.
The Problem
Most businesses struggle to identify recurring pain points in their market. They spend hours manually analyzing customer feedback, reviews and support tickets. They miss patterns that repeat across different data sources. They make decisions based on gut feeling instead of data-driven insights. They waste resources solving symptoms instead of root causes.
I have seen this firsthand, companies drowning in data but starving for insights.
The Solution
MPI uses AI to automatically aggregate data from multiple marketplaces. It identifies recurring pain patterns using natural language processing, clusters similar issues together even when described differently, prioritizes pains by frequency, severity and business impact, and generates insights and products hypotheses.
Think of it as having a research team that never sleeps, constantly analyzing what your market is really saying.
Current Status:
I am 13 days away from launch. Here is what is already done:
-Core AI engine: Pattern recognition and clustering working.
-Stripe PoC completed: Full subscription and credit system tested with real API calls.
-Three pricing tiers defined: Starter ($19/mo), Growth ($49/mo), Enterprise ($149/mo).
-Pay-as-you-go credits: $0.49 per credit for flexible usage.
-Webhook flow validated: Checkout, subscription updates and cancellations tested.
-Customer portal tested: Users can manage their plans.
-Credit management logic: FIFO logic with expiration handling validated.
Just finished this week:
Complete Stripe webhook integration tests (checkout, subscription updates, cancellations), automated credit granting based on subscription plans, and Customer Portal flow for self-service plan management.
What I am working on RIGHT NOW:
-Implementing repositories, services and routes for Stripe integration
-Preparing the front end to consume the credit logic
-Database models for production
-FastAPI backend endpoints
Replies
Update: Stripe integration complete
Yesterday I mentioned I was working on implementing repositories, services and routes for Stripe integration.
Today it's done:
- CreditService implemented with FIFO logic (consumes credits that expire soonest first)
- Idempotency built in (users don't pay twice for the same resource)
- Balance validation for list endpoints (must have credits > 0 to access)
- Detail endpoints consume credits (1 credit per signal/cluster/hypothesis detail)
- Transaction history endpoint for transparency
- Balance endpoint for real-time UI updates
Key architecture decisions:
- Atomic transactions (all or nothing)
- FIFO by expires_at (validated in PoC, now in production code)
- Idempotency via resource_type + resource_id tracking
- Configurable credit costs (easy to adjust pricing strategy)
Next: Integrating credit consumption into the frontend endpoints and preparing for beta testing. 12 days to launch.
Update: Securing public registration and checkout flows
Yesterday I mentioned preparing for beta testing. Today I focused on securing the entry points and payment flows to ensure a smooth onboarding experience.
Today it's done:
Public registration opened (removed admin-only restriction)
Automatic welcome bonus: 50 free credits granted instantly on signup
Secured Stripe Checkout endpoint (backend-controlled redirect URLs, auth via JWT)
Added flexible pay-as-you-go credit purchases (custom quantity, min 10 to cover Stripe fees)
Key security and architecture decisions:
Zero-trust checkout: Client never sends user_id or redirect URLs (prevents open redirect and ID spoofing)
Role enforcement: Public signup strictly forces role="user" at the backend level
Configurable onboarding: Welcome bonus amount tied to settings (no hardcoded magic numbers)
Next: Building the frontend Paywall Interceptor (handling 402 responses globally) and the Billing UI.
11 days to launch.
Update: Billing UI + Customer Portal live
Yesterday I promised the Billing UI and Paywall Interceptor. Today the Billing UI is done and I went further - integrated the full Stripe Customer Portal.
What's shipped:
-Real-time billing dashboard (credits balance, transaction history, usage breakdown)
-Smart plan management button ("Manage Subscription" opens Stripe Portal for upgrades/downgrades/cancellations)
-Flexible credit purchases (custom quantity input, min 10 credits, real-time price calculation)
-Secure checkout flow from landing page (authenticated users → direct Stripe checkout, unauthenticated → /login?plan=xxx → auto-redirect after login)
-Stripe Customer Portal configured (proration, plan switching, invoice downloads all working)
Key decisions:
Customer Portal over custom UI: Stripe's native portal handles upgrades/downgrades/cancellations with proration. No need to reinvent the wheel.
Auth-aware navigation: Landing page buttons change based on login state (Login/Dashboard, Get Started/Logout)
What's left:
Paywall Interceptor (global 402 handler) - moved to tomorrow
10 days to launch.
Update: Paywall Interceptor + Database Migration shipped
Yesterday I shipped the Billing UI and Customer Portal. Today I went deeper into the monetization flow and hit a critical infrastructure issue.
What's shipped:
-Paywall Interceptor (global 402 handler) - when users hit credit limits, a contextual modal appears with 3 upgrade plans (Starter $19, Growth $49, Enterprise $149) + flexible credit purchases
-Smart PaywallModal - context-aware: Free users see upgrade plans + credit input, subscribed users see only credit input + "Manage Subscription" link to Customer Portal
-Real-time credit calculation - flexible input (min 10 credits, $0.49/credit) with live price updates, consistent across BillingPage and PaywallModal
-Auth flow improvements - /register now returns JWT for auto-login, password validation, redirect to dashboard after signup
-Database architecture migration - moved from direct Turso remote connections to local replica with sync (fixed persistent 502/EOF errors).
Key decisions:
Local replica over direct remote: Turso's libsql driver has bugs with persistent HTTP connections (502 Bad Gateway, unexpected EOF). Local replica with sync_url solves this - reads are instant from local file, writes sync to cloud. Trade-off: slightly more complex sync logic, but 100% reliable.
Context-aware paywall: Instead of generic "buy credits" modal, the PaywallModal checks subscription status via useQuery. Free users get upgrade options, subscribed users get credit purchases. Reduces friction and confusion.
No separate success/cancel pages: Stripe redirects to /app/billing?payment=success|cancel. BillingPage reads query param, shows contextual banner (auto-dismiss 5s + manual close), and force-refetches credit/subscription data. Cleaner UX, less code.
What's left:
-End-to-end payment testing (all scenarios: credit purchase, subscription upgrade, downgrade, cancellation)
-Frontend polish and edge cases
-Deploy to production (Render + Turso sync validation)
9 days to launch.
Update: Smart Caching, Plan Proration & E2E Payment Testing shipped
Yesterday I shipped the Paywall Interceptor and Database Migration. Today was all about the complex monetization logic and making the app feel snappy without hammering the database.
What's shipped:
- Smart Cache Strategy - BillingPage now forces a full refresh on every mount (critical for financial data). All other pages (Dashboard, Lists, Details) use a manual refresh button with a 5-minute cache. This drastically reduces Turso read costs and prevents UI flashes.
- Plan Upgrade/Downgrade with Proration - Implemented the complex webhook logic to detect plan changes. When a user upgrades/downgrades via Stripe Customer Portal, the system automatically calculates and grants proportional credits based on the remaining days in the billing cycle.
- Turso Sync Fixes - Fixed the "stream not found" errors on writes.
- End-to-End Payment Testing - Validated 11 critical scenarios including credit purchases, subscription lifecycle, webhook idempotency (preventing double credits), and webhook security.
Key decisions:
- Manual vs Auto Refresh: Instead of auto-refreshing every page (which would spam the Turso replica sync), I added a manual refresh button for Dashboard and Lists. Billing remains auto-refreshed. This gives users control while saving API calls.
- Proration Logic: Instead of just giving full plan credits on upgrade, I calculated `(days_remaining / total_days) * new_plan_credits`. This is fairer and aligns with how Stripe handles monetary proration.
- Webhook Idempotency: Proved that our `stripe_webhook_events` table successfully prevents duplicate processing when Stripe resends events (tested via Stripe CLI resend).
What's left:
- Scenario 6 deep dive (Paywall edge cases with expired credits)
- Final frontend polish
- Production deploy (Render + Turso)
8 days to launch.
Last update I mentioned "8 days to launch".
The platform is stable, webhooks are bulletproof, and the core monetization logic is fully tested in production. So, we're pulling the launch forward to July 15th.
Today was all about final polish, infrastructure reliability, and getting ready to talk to customers.
What's shipped today:
Brand Consistency - Standardized the "Painkiller Credits" terminology across the entire UI (Paywall, Billing, Landing Page). It's not just a generic "credit", it's our core value metric.
Pricing Strategy Finalized - Locked in the final pricing ladder.
What's next:
Final monitoring setup and load testing.
If you're building a SaaS, running an agency, or consulting, and you want to validate market demand with real data (not just opinions), just create an account. Every new signup gets 5 free Painkiller Credits to explore the platform and test the core features.
See you on July 15th.