Mulligan (Pyq AI) — AI Automation Platform for Insurance

Context

At Pyq AI, we built Mulligan — an AI automation platform for insurance brokerages. Insurance brokers were spending 15+ hours weekly on manual data entry, policy comparisons, and commission reconciliation. This work didn't scale: to 10x revenue, they'd need to 10x headcount.

We built 5 core products to automate these workflows: Quoting, Submissions, Proposals, Policy Comparison, and Commissions. As the AI Product Engineer at this seed-stage startup, I wore every hat — building product features and transforming our go-to-market from enterprise sales to self-serve Product-Led Growth.

Jump to Section

1. PLG Infrastructure: Stripe, Metronome, and Slack

Challenge: Insurance brokers face extreme seasonality—processing 50 policies in January (renewal season) and only 5 in July. Flat subscription pricing ($99/mo unlimited) punishes this pattern, charging the same whether they use the product heavily or barely at all. We needed self-serve pricing aligned with customer value that supported seasonal usage without requiring sales calls or contract negotiations for a seed-stage startup.

What I Built: Built complete self-serve billing infrastructure combining Stripe for payments and Metronome for usage tracking.

• Credit-based pricing: Customers buy credits upfront (Free: 10, Plus: 30, Pro: 250, Team: 1250), consume them per action, with 1-year rollover
• Stripe integration: Instant upgrade flow (<2 min from free → paid), no credit card required for free tier
• Metronome tracking: Every user action sends billing events to track usage.
• Organization-scoped billing: Every event tagged with org ID for per-organization usage limits and invoicing

Slack notifications provide real-time visibility into user signups, upgrades, and feature usage

Key Technical Decisions:

• Metronome over building in-house: Stripe handles payments but can't track complex usage patterns. Metronome specializes in usage-based billing with meters and tiered pricing—gave us production-ready infrastructure immediately instead of spending months building it ourselves.
• Credit consumption on end states: Built into our backend—credits are only consumed when a process successfully reaches an end state (success, fail, or denied). This ensures users only pay for completed operations, not abandoned or interrupted ones.
• Two-stage billing: Users perform actions (real-time event tracking) → Metronome accumulates usage → Monthly invoices calculated based on total consumption. Separates event collection from billing for reliability.

Key Product Decisions:

• Credits over subscriptions: Aligns pricing with value—busy months cost more, slow months cost less. Credits roll over for 1 year, so customers don't lose unused credits. Supports seasonal insurance workflows.
• No card for free tier: Users can process features worth 10 credits freely without payment. See value before paying. Removes signup friction.
• Instant self-serve upgrade: Free → paid in <2 minutes via Stripe Checkout. No sales calls. Any friction in upgrade flow kills PLG conversion.
• Tiered volume discounts: Subscription credits are cheaper than pay-as-you-go credits, but also stickier—customers commit to monthly payments. Incentivizes users to upgrade to subscription plans as usage grows. High-volume customers automatically pay more, so revenue scales with customer success.

Impact:

• Self-serve signup and upgrade: no sales calls or contracts required
• Usage-based revenue scales with customer success: customers pay proportional to value, supporting seasonal workflows
• Free → paid conversion: users see value before paying
• Metronome enables the team to track usage and monitor platform activity

2. Setting Up Live Demos

Challenge: Converting website visitors to sign-ups is hard when the product is complex. Insurance automation isn't something people can understand from screenshots or marketing copy—they need to see it work. However, if live demos take too long to load, this will cause users to leave before seeing results. We needed interactive demos that proved functionality while loading fast enough to keep users engaged.

What I Built:

• Interactive live demo system for Policies and Commissions products embedded on landing page
• Isolated demo instances running on pre-loaded sample insurance documents
• Parallelized Google Cloud Functions reducing latency from 150s → 15s (10x improvement)
• Real-time progress indicators showing processing steps
• Demo-specific API endpoints processing sample data instantly
• Next.js frontend with WebSocket connections for live status updates
• Zero friction access (no login required to try demos)

Live demo of the Policies product — side-by-side policy comparison with automated analysis

Live demo of the Commissions product — automated commission reconciliation from carrier statements

Key Technical Decisions:

• Parallelized cloud functions: Initial demos took 150 seconds (users would leave). Parallelized document processing across multiple cloud functions cut latency to 15 seconds. Critical for user engagement.
• Pre-loaded sample data: Visitors might not have insurance documents readily available to test the product. We provide sample documents so users can see the product work immediately—removing the barrier of "I don't have a document to try" and pushing them further down the conversion funnel.
• WebSocket status updates: Real-time progress indicators show each processing step. Users see the system working (parsing PDF, extracting data, comparing policies) rather than staring at a loading spinner.

Key Product Decisions:

• No signup required: Demos work immediately without account creation. Reduces friction—users see value before committing. Classic PLG strategy.
• Real processing over fake mockups: Run actual processing on sample documents instead of showing static screenshots. Builds trust—users see genuine functionality, not fake demos.
• 15-second performance threshold: At 150s, users left. At 15s, they stayed and completed the demo. Performance directly impacted conversion from visitor → signup.

Impact:

• Website visitors try Policies and Commissions features instantly without signup
• Users see real output before creating an account
• 10x performance improvement (150s → 15s) kept users engaged through full demo
• Supported self-serve PLG strategy by showing value upfront

3. Building the Quoting System

Challenge: Insurance carriers don't offer APIs—they have web portals designed for humans to manually click through forms. Getting quotes from multiple carriers required brokers to spend ~1 hour per customer manually visiting each carrier website, filling forms, and copying results. This manual process was slow, expensive, and didn't scale.

What I Built: Built an automated quoting system that processes customer information, interacts with multiple carrier portals programmatically, and handles the complexity of different carrier formats and requirements. The system includes monitoring, error handling, and parallel processing capabilities to ensure reliability and speed.

Automated quoting system processing multiple carriers in parallel—form filling, submission, and data extraction without human intervention

Key Technical Decisions:

• Docker containerization: Browser automation scripts are extremely sensitive to environment differences (browser versions, screen sizes, font rendering). Docker ensures identical execution every time.
• Parallel processing: Running multiple carriers simultaneously instead of sequentially dramatically reduced total quote time from cumulative processing to the time of the slowest single carrier.

Key Product Decisions:

• Graceful degradation: If automation fails, system falls back to manual quote request rather than blocking the user. Automation improves UX but doesn't create new failure modes.
• Carrier prioritization: Focus automation on high-volume carriers first. 80/20 rule—automate the 5 carriers that represent 80% of quote volume.
• Slack monitoring: Real-time alerts when carrier integrations break (they change UIs frequently). As a seed-stage startup, we needed immediate visibility.

Impact:

• Quote time: ~1 hour → <10 minutes (per customer)
• Automated ~90% of quoting workflows
• Parallel processing handles multiple carriers simultaneously
• Brokers can quote more customers per day, increasing revenue capacity

4. Advanced Policy Comparison

Challenge: Different insurance carriers use wildly inconsistent terminology for the same coverage concepts. One policy might call it "Comprehensive and Collision Limit" while another says "Automotive coverage - comprehensive and collision." Brokers waste hours manually matching up equivalent items across policies to do apples-to-apples comparison. The insurance industry has no standardized terminology.

What I Built:

• Semantic matching system that intelligently groups and standardizes inconsistent insurance terminology across carriers
• Ability to seamlessly switch between original carrier data and standardized unified views
• Original names dropdown showing all unified terminology for full transparency
• Comprehensive processing across multiple policy sections (coverages, limits, deductibles, endorsements, etc.)

Within-policy consolidation: Left shows item names, right shows Policy1 and Policy2 columns—related items merged within each policy to reduce clutter

Cross-policy standardization: Policy1 and Policy2 had different names for the same coverage—now unified under one standardized name for apples-to-apples comparison

Key Technical Decisions:

• Domain-aware matching: Built semantic matching that understands insurance context—recognizing that identical terms can mean different things across policy types (e.g., "collision" in auto vs property insurance means different coverage).
• Transparency by default: Preserve all original carrier terminology in the background while displaying unified names. Brokers can always drill down to see exactly what each carrier called a specific item.

Key Product Decisions:

• View switching: Let brokers switch between different data views. Builds trust—they can verify the system's matching decisions.
• Full transparency: When items are unified, brokers can always see the original carrier terminology. Transparency prevents "black box" concerns.
• Broker verification: Show unified view as default after processing, but always allow returning to original data. The system augments broker expertise, doesn't replace it.

Impact:

• Policy comparison: hours of manual matching → seconds of processing
• Apples-to-apples comparison across carriers with different terminology
• Semantic understanding handles inconsistent naming (e.g., "CGL" = "General Liability" = "Commercial General Liability")
• Brokers can confidently identify coverage gaps and recommend best policies

5. Templates and Proposals

Challenge: Insurance brokers spend hours manually creating branded proposals—copying policy data into Word docs, adding logos, formatting tables. Every agency has unique branding requirements. We needed proposal automation that preserved each agency's exact visual identity while filling in policy-specific data.

What I Built:

• Automated PDF → HTML template conversion pipeline
• Organization-scoped template library for multi-agency support
• Automated proposal generator with editable interface for manual adjustments
• Multi-mode PDF export (single-page, multi-page, smart pagination)

How It Works: Agencies upload their branded proposal PDF once. We convert it to an HTML template with placeholders. Then generate unlimited proposals for any policy—preserving the agency's logo, colors, and layout while filling in policy-specific data.

Key Technical Decisions:

• Automated PDF conversion: Built conversion pipeline that preserves visual fidelity (logos, colors, fonts, layouts) while extracting semantic structure for data injection. Delivers higher accuracy than template-based approaches.
• Presigned S3 URLs for images: Template images stored in S3, served via expiring URLs. Avoided CORS issues during PDF export while maintaining security.
• Smart pagination: Multi-page proposals automatically break at logical boundaries to prevent awkward content splits across pages.

Key Product Decisions:

• Brand consistency over flexibility: Let agencies upload their own PDF templates. System preserved exact branding rather than forcing a generic template. Higher adoption.
• Edit before export: Generated proposals are editable (WYSIWYG). Automated filling handles ~90% correctly, brokers fix the rest. Builds trust while saving time.

Impact:

• Proposal generation: hours → minutes
• Perfect brand preservation (logos, colors, layouts)
• Template reuse across all proposals
• Professional client-ready PDFs with one click

6. ACORD Form Automation

Challenge: ACORD forms (125, 126, 140) are standardized insurance PDFs with 50+ fields that brokers manually fill for every carrier submission. This tedious data entry wastes hours per submission and creates bottlenecks in the quoting workflow. We needed automation that could both extract data from filled forms AND populate blank forms from customer information.

What I Built: Built an automated ACORD form system that handles bi-directional workflows: extracting structured data from broker-uploaded forms and auto-filling blank ACORD PDFs from customer data. The system includes a review interface in the Submissions module where brokers can verify and adjust auto-filled forms before final submission.

Key Product Decisions:

• Broker review before submission: Auto-filled 80-90% of fields accurately but let brokers verify and correct before sending to carriers. This builds trust while dramatically reducing manual work.
• Bi-directional workflow: Parse uploaded PDFs OR fill blank forms. Covers both inbound flows (extracting client data from existing forms) and outbound flows (generating new carrier submission forms).
• Integration with submission pipeline: ACORD automation sits within the broader Submissions product, enabling seamless handoffs to carrier portals.

Impact:

• 80-90% auto-fill accuracy across ACORD 125, 126, and 140 forms
• Hours of manual form entry → minutes of verification and adjustment
• One-click conversion: uploaded customer documents → carrier-ready ACORD PDFs
• Enabled self-serve, automated carrier submission workflow

7. Landing Page

Designed and built the complete GTM funnel at usemulligan.com using Next.js. The landing page serves as our entire sales team—replacing demo calls with self-serve signup.

Key GTM Strategy:

• Embedded live demos: Visitors see real AI processing (Policies + Commissions) without signup
• Transparent pricing: Credit calculator shows exact costs upfront—no hidden fees
• Zero friction signup: 10 free credits, no credit card required
• <5 minute onboarding: Land → Try demo → Sign up → Use product
• Value-first approach: Users see functionality before paying

Built with Next.js for fast load times (<2s), SEO optimization, and seamless integration with Stripe checkout. The page showcases all products, pricing tiers, and instant signup—designed to convert visitors without human intervention.

8. Documentation

Built comprehensive product documentation for Mulligan's self-serve PLG model using Mintlify. The docs enable users to onboard, troubleshoot, and integrate without human support.

Live Docs: docs.usemulligan.com

The documentation includes getting started guides, product-specific tutorials, API references, and troubleshooting resources—guiding users on how to use the platform.

Summary

Stack: Next.js, FastAPI, Stripe, Metronome, Docker, AWS, Google Cloud, S3

Timeline: June 2025 - Present

Company: Pyq AI (YC W23) — seed-stage startup

Role: AI Product Engineer

Live Product: usemulligan.com