iri Notes

Note

PIVOT_STRATEGY

◈ Obsidian March 18, 2026

Pivot Strategy: AI-Powered Remote Hardware Debugging

Last updated: 2026-03-18 Status: Strategic exploration Authors: Angie (CEO), Hosung (CTO)

TL;DR

  • We’re pivoting away from iri (AI token management) because we lack a defensible moat and the product category isn’t differentiated enough to win.
  • The new product reproduces and debugs hardware/firmware failures remotely by capturing a structured “bug snapshot” from deployed devices and running an AI-assisted virtual debug environment.
  • The core moat is a data flywheel: every captured bug snapshot improves root-cause accuracy across customers, backed by Hosung’s systems/virtual reproduction expertise.
  • The first 90 days focus on Nvidia network validation, building a narrow working prototype for one chip family/bug class, deploying to a few teams, and converting initial teams to paid.

Table of Contents

  1. Why We're Pivoting
  2. The Problem
  3. The Product
  4. Market Landscape
  5. Competitive Analysis
  6. Why Us
  7. Go-to-Market
  8. Business Model
  9. 90-Day Execution Plan
  10. Risks & Mitigations
  11. YC Reapplication Strategy

1. Why We're Pivoting

iri (AI token management platform) occupies the same space as Portkey ($12M raised) and Helicone — LLM proxy, cost tracking, policy enforcement. We have no moat. YC rejected us (top 10% applicants) likely because the product lacks a unique founder insight.

What we have that matters:

  • Hosung spent 3 years at Nvidia as a systems OS engineer, physically driving to the office to debug hardware because remote debugging was impossible
  • He's already built a technique to reproduce specific hardware bugs in a virtual environment — without physical hardware access
  • This is a problem nobody is solving with AI

What we're leaving behind:

  • The iri codebase (Next.js dashboard, Rust proxy, CLI) — potentially open-sourceable for credibility
  • 2 beta test teams, no paying customers
  • A product category where we can't win

2. The Problem

The Pain

Hardware and firmware engineers cannot debug remotely. When a device fails — whether it's a GPU in a data center, a sensor on a factory floor, or an MCU in a shipped consumer product — the debugging workflow looks like this:

  1. Receive a bug report or crash alert
  2. Try to reproduce from logs (usually fails — insufficient context)
  3. Physically travel to the hardware or have it shipped to you
  4. Connect JTAG probe, serial debugger, or oscilloscope
  5. Spend hours stepping through firmware to find root cause
  6. Fix, flash, test on the physical board
  7. Repeat

Step 3 is the bottleneck. It costs:

  • Time: Days to weeks of delay per bug
  • Money: Travel, shipping, dedicated lab space, idle engineering hours
  • Scale: A 50-person firmware team can only debug as many bugs as they have physical boards and physical access

Why It's Getting Worse

  • Remote work is standard. Hardware engineers can't work from home if debugging requires physical presence.
  • AI hardware is proliferating. Custom chips (GPUs, NPUs, TPUs, edge AI) are shipping in unprecedented volumes. More hardware = more firmware bugs.
  • Robotics is exploding. Robots deployed in the field can't be shipped back for every firmware issue.
  • IoT fleet sizes are growing. Companies ship millions of devices. Reproducing field failures at scale is impossible with physical boards alone.
  • Firmware complexity is increasing. Multi-core, multi-peripheral, real-time constraints — bugs are harder to isolate.

Who Feels This Pain

Segment Size Pain Intensity Budget
AI hardware companies (GPU, NPU, custom accelerators) 100+ companies Extreme — failed training runs cost millions Very high
Robotics companies (post-Series A) 1,000+ companies High — field-deployed hardware High
Automotive embedded (ADAS, EV) 500+ tier-1/2 suppliers High — safety-critical, regulated Very high
Medical devices 1,000+ companies High — regulated, slow debug cycles High
Industrial IoT 5,000+ companies Medium-high — deployed sensors/controllers Medium
Consumer electronics (wearables, smart home) 10,000+ companies Medium — high volume, hard to reproduce Medium

3. The Product

One-Liner

Reproduce and debug hardware/firmware failures without physical hardware — using AI-powered virtual environments.

How It Works

┌─────────────────────────────────────────────────────────────┐
│                                                             │
│   DEVICE IN THE FIELD                                       │
│   ┌─────────────┐                                           │
│   │ Firmware     │──── crash dump, telemetry, traces ────┐  │
│   │ crashes      │                                       │  │
│   └─────────────┘                                       ▼  │
│                                              ┌──────────────┤
│                                              │  CLOUD       │
│                                              │              │
│   ENGINEER (REMOTE)                          │  1. Capture  │
│   ┌─────────────┐    virtual env link        │  2. Analyze  │
│   │ Opens debug  │◄──────────────────────────│  3. Build    │
│   │ session      │                           │     virtual  │
│   │              │──── interactive debug ────►│     env      │
│   └─────────────┘                           │              │
│                                              └──────────────┤
│                                                             │
└─────────────────────────────────────────────────────────────┘

Core Capabilities

Layer 1: Bug Capture (The On-Device Agent)

  • Lightweight agent (~5KB) runs on the target device
  • On crash/fault: captures register state, stack trace, peripheral states, memory snapshot, execution trace
  • Packages into a structured "bug snapshot" and uploads to cloud
  • Works over any connectivity (BLE, Wi-Fi, LTE, USB, serial)
  • Value even without simulation: structured, searchable, shareable crash reports — 10x better than raw crash dumps

Layer 2: AI Root Cause Analysis

  • AI ingests the bug snapshot + device's firmware binary + hardware datasheet
  • Cross-references against database of known failure patterns (grows with every bug captured across all customers)
  • Outputs: probable root cause, affected code paths, similar past bugs, suggested fix
  • This is the data flywheel moat — every bug captured makes the AI smarter

Layer 3: Virtual Debug Environment

  • For supported chip architectures: reconstructs a virtual environment from the bug snapshot
  • Engineer can interactively step through the failure — set breakpoints, inspect registers, modify state, replay execution
  • No physical board needed
  • Start with: ARM Cortex-M (largest embedded market), RISC-V (open architecture, growing fast), NVIDIA GPU (Hosung's deep expertise)
  • Uses existing emulation primitives (QEMU, Renode) as base layer + proprietary reconstruction on top

Layer 4: Collaborative Debugging

  • Bug snapshot becomes a shareable link (like a GitHub issue, but for hardware)
  • Any engineer on the team can open it, see the exact device state, debug it
  • Comments, annotations, resolution tracking
  • Integration with existing tools: Jira, Linear, GitHub Issues

Product Tiers

Tier What You Get Target
Capture On-device agent + crash dashboard + AI analysis Any hardware team — fast time to value
Debug Capture + virtual debug environments + interactive replay Teams with remote debugging pain
Platform Debug + fleet-wide pattern analysis + CI/CD integration + API Larger teams shipping at scale

4. Market Landscape

Market Sizing

Embedded systems market: $130B+ (2025), growing 6-7% CAGR Developer tooling for embedded: ~$5B (EDA tools, debuggers, IDEs, testing) IoT device management/observability: ~$2B, growing 25%+ CAGR

Our addressable market:

  • 1.5M+ firmware/embedded engineers worldwide
  • Average tooling spend per engineer: $2,000–$10,000/year
  • Even capturing 1% of firmware engineers at $200/month = $36M ARR

Funding Environment (Favorable)

  • US semiconductor startup funding: $6.2B in 2025 (85% YoY increase, all-time record)
  • 12 rounds of $100M+ in Q4 2025 alone
  • DeepTech share of VC portfolios: grew from 8.5% → 12.2% (2022–2025)
  • US government tailwind: CHIPS Act + NSF funding $20M/node for cloud-accessible hardware labs
  • YC expanding to 4 batches/year, actively funding hardware/embedded companies

Category Validation

  • Synopsys launched Electronics Digital Twin (eDT) platform in March 2026 — validates digital twin for hardware
  • Nordic Semiconductor acquired Memfault for $120M in June 2025 — validates IoT device intelligence as an acquisition category
  • Embedder (YC S25) gaining traction at Tesla, Nvidia, Medtronic — validates AI for firmware as a product category

5. Competitive Analysis

Direct Competitor Map

                    WRITES CODE          FINDS BUGS           DEBUGS BUGS
                    (development)        (observability)       (root cause)

  AI-POWERED        Embedder ✓          (nobody) ✗            (nobody) ✗  ← THE GAP
                    YC S25, $550K
                    3K+ engineers                              WE GO HERE

  TRADITIONAL       IAR, Keil           Memfault ✓            Lauterbach ✓
                    ARM MDK             $120M acq by Nordic    JTAG tools
                                        100+ customers         $5K-$30K/seat
                                        Bose, Lyft, Logitech  15K+ chips

Deep Competitive Breakdown

Embedder (YC S25) — AI Firmware Code Generation

  • What they do: AI that reads datasheets and generates driver code (C++/Rust). Hardware-aware Copilot for firmware. CLI agent can flash and test on real hardware.
  • Chips: 300+ MCU variants (STM32, ESP32, nRF52, RISC-V, NXP, RP2040)
  • Pricing: Free tier → $20/month Pro → Enterprise custom
  • Traction: 3,000+ engineers at Tesla, Nvidia, Medtronic, Boston Scientific, General Dynamics
  • What they DON'T do: No post-deployment debugging. No crash reproduction. No virtual environments. No fleet observability. They help you write firmware, not fix it when it breaks.
  • Our relationship: Complementary. Engineer uses Embedder to write code, uses us when it breaks. Potential integration partner.

Memfault (Acquired by Nordic, $120M) — IoT Observability

  • What they do: Crash diagnostics, fleet health monitoring, OTA updates for deployed devices. Collects coredumps, deduplicates, symbolication, dashboards.
  • Chips: ARM Cortex-M/R, ESP32, Linux, Android
  • Pricing: Free (10 devices) → $0.10/device/month → Enterprise custom. Typical contracts $12K–$45K/year.
  • Traction: 100+ customers including Bose, Lyft, Whoop, Panasonic, Logitech. ~$7.2M ARR (end of 2024).
  • What they DON'T do: No AI-powered analysis. No interactive debugging. No virtual environments. No root cause analysis — they tell you what crashed, not why. No code-level debugging tools.
  • Our relationship: We sit on top of Memfault. They capture the crash; we analyze and reproduce it. Also a potential acquisition threat if they build AI debugging.

Lauterbach TRACE32 — Traditional JTAG Debugging

  • What they do: Industry-standard JTAG/SWD debug hardware + software. 15,000+ chips, 150+ architectures. Some remote access and digital twin support.
  • Pricing: $5,000–$30,000 per hardware probe + software license
  • What they DON'T do: No AI. No cloud-native workflow. No crash capture from deployed devices. Requires physical probe connected to hardware. Legacy UX.
  • Our relationship: We replace the need for physical Lauterbach probes in many debugging scenarios.

Synopsys eDT / Cadence / Siemens — EDA Giants

  • What they do: Pre-silicon design, verification, and simulation. Synopsys just launched digital twin platform (March 2026). Cadence has ChipStack AI agent.
  • Focus: Chip designers, not firmware engineers. Pre-silicon, not post-deployment. Enterprise contracts $100K–$10M+.
  • Our relationship: Different market. They serve chip designers during the design phase. We serve firmware engineers after the chip is real and deployed.

Renode / QEMU — Open-Source Emulators

  • What they do: Virtual hardware frameworks. Renode (Antmicro) simulates multi-node embedded systems. QEMU emulates processor architectures.
  • Limitations: Require deep expertise to configure. No AI. No crash capture. No collaboration. No managed service.
  • Our relationship: We use these as building blocks. Our value is the AI layer that auto-configures emulation from a bug snapshot, plus the collaboration and analysis features on top.

Wokwi — Browser-Based Simulator

  • What they do: Online simulator for Arduino, ESP32, STM32, RPi Pico. VS Code integration.
  • Focus: Education, prototyping, hobbyists. Not enterprise debugging.
  • Our relationship: Not competitive. Different market entirely.

Competitive Moat Assessment

Moat Type Embedder Memfault Lauterbach Us
AI/ML Strong (code gen) None None Strong (root cause)
Data flywheel Datasheet library Crash data (no AI on it) None Bug pattern DB
Hardware depth Medium (MCU focus) Medium (ARM, ESP32) Very deep (15K chips) Deep (Nvidia + growing)
Switching cost Low Medium (SDK integration) High (hardware lock-in) Medium-high (SDK + data)
Network effects None None None Cross-customer bug patterns

6. Why Us

Founder-Market Fit

Hosung (CTO):

  • 3 years at Nvidia as systems OS engineer — power management, display systems, embedded hardware
  • Lived the exact pain: drove to the office to debug hardware that couldn't be diagnosed remotely
  • Already built a working technique to reproduce specific hardware bugs in a virtual environment
  • Deep C++, systems programming, hardware-software interface, performance optimization
  • Understands the firmware debugging workflow at a level most software engineers never will

Angie (CEO):

  • NYU ITP (physical computing + creative technology) — understands hardware-software intersection
  • 4 years product design at startups — full design-to-frontend pipeline
  • Built a custom ERP platform and QC inspection app from 0→1 — knows how to ship complex B2B products
  • Can code (Python, JS, SQL), prototype hardware (Arduino), and design the UX
  • Firmware debugging tools have notoriously terrible UX — a product designer who can also code is a genuine differentiator in this market

What We Can Do That Others Can't

  1. Hosung is the customer. He debugged Nvidia hardware for 3 years. He knows every failure mode, every tool limitation, every wasted hour. Embedder was founded by software engineers who learned hardware. Memfault was founded by wearable/consumer device people. Neither has a systems OS engineer from Nvidia.

  2. The technique exists. Hosung has already demonstrated virtual hardware bug reproduction for a specific bug class. This isn't theoretical — it works. The AI layer generalizes what he does manually.

  3. Angie can design the experience. Every firmware debugging tool on the market looks like it was designed in 2005. The company that makes hardware debugging feel like a modern developer tool wins.

7. Go-to-Market

Phase 1: Nvidia Network (Months 1–3)

Target: Hosung's former colleagues at Nvidia and engineers who left Nvidia for AI hardware startups (Tenstorrent, Cerebras, Groq, etc.)

Strategy:

  • Personal outreach to 20 engineers Hosung knows
  • Offer free early access in exchange for feedback and case studies
  • Focus on GPU/compute debugging pain (training run failures, driver issues, power management bugs)
  • Goal: 5 teams actively using the product

Why this works: Trust is pre-built. The pain is understood. These are the richest buyers in hardware right now (AI infrastructure).

Phase 2: Expand to Embedded (Months 3–6)

Target: Firmware teams at robotics companies, automotive suppliers, medical device companies (20–200 engineers)

Strategy:

  • Launch support for ARM Cortex-M (largest embedded market)
  • Content marketing: "How we debug [specific chip] without the board" technical blog posts
  • Embedded conference presence (Embedded World, etc.)
  • Partnership with Embedder (they write firmware, we debug it)
  • Goal: 20 paying teams

Phase 3: Platform (Months 6–12)

Target: Larger hardware organizations needing fleet-wide debugging intelligence

Strategy:

  • Cross-customer bug pattern database becomes the selling point
  • CI/CD integration (catch firmware bugs before deployment)
  • API for custom integrations
  • Enterprise sales motion
  • Goal: 50 paying teams, recognizable logos

8. Business Model

Pricing Strategy

Plan Price Includes
Free $0 5 bug captures/month, AI analysis, 1 engineer
Team $200/engineer/month Unlimited captures, virtual debug environments, collaboration, 3 chip architectures
Enterprise Custom Unlimited everything, custom chip support, on-prem deployment, SLA, API access

Revenue Targets

Milestone Timeline ARR
5 free teams (validation) Month 3 $0
10 paying teams (avg 5 eng) Month 6 $120K
30 paying teams Month 9 $360K
50 paying teams + 2 enterprise Month 12 $800K–$1.2M

Unit Economics

  • CAC: Low initially (Hosung's network), then content/conference-driven. Estimated $2K–$5K per team.
  • LTV: $200/eng/month × 5 engineers × 24 months = $24K per team
  • LTV/CAC: 5–12x (healthy)

9. 90-Day Execution Plan

Week 1–2: Validate

  • Hosung: List 20 former Nvidia colleagues and contacts at AI hardware companies
  • Hosung: Call 10 of them. Script: "When was the last time you had to physically go to the office or ship a board to debug a firmware issue? Walk me through what happened."
  • Angie: Document every call. Extract patterns: frequency of pain, current workarounds, budget authority, willingness to pay
  • Decision gate: Do 7+ out of 10 confirm this is a real, frequent, painful problem?

Week 3–4: Prototype

  • Hosung: Generalize the existing virtual debug technique to work for one more bug class
  • Build minimal bug capture agent (crash dump → structured snapshot → upload)
  • Build minimal web viewer (open a bug snapshot, see the state, basic navigation)
  • Angie: Design the core UX flows (bug capture → analysis → debug session)

Week 5–6: Alpha

  • Deploy to 3 friendly teams from Hosung's network
  • Support one chip architecture (ARM Cortex-M or NVIDIA GPU — whichever validation calls indicate)
  • AI root cause analysis: even if basic, must provide value beyond raw crash dump
  • Collect feedback aggressively

Week 7–8: Iterate

  • Fix top 3 pain points from alpha users
  • Add second chip architecture
  • Improve AI analysis accuracy based on real bug data
  • Begin writing technical content (blog posts, debug case studies)

Week 9–10: Early Revenue

  • Convert 2 alpha teams to paid ($200/eng/month)
  • Expand to 5 more teams via referrals from alpha users
  • Add collaborative features (shareable bug links, team comments)

Week 11–12: YC Prep

  • Compile metrics: teams using, bugs captured, time saved, NPS
  • Record demo video: real bug → capture → AI analysis → virtual debug → fix
  • Draft YC application with concrete traction data
  • Apply to YC W26 (or next available batch)

10. Risks & Mitigations

Risk 1: Generalization Is Harder Than Expected

Risk: Hosung's technique works for specific Nvidia hardware. Generalizing to ARM Cortex-M, RISC-V, and other architectures may be much harder than anticipated. Mitigation: Start with the narrowest possible scope (one chip family, one bug class). Even a narrow tool that works is more valuable than a broad tool that doesn't. Layer 1 (bug capture) and Layer 2 (AI analysis) provide value without Layer 3 (virtual environments).

Risk 2: Memfault Adds AI Debugging

Risk: Memfault (now Nordic-owned, well-funded) could build AI-powered debugging on top of their existing crash data. Mitigation: Move fast. Our advantage is that we're building debugging-first, not adding it to an observability product. Also, Memfault's acquisition by Nordic may slow their product velocity (integration, corporate priorities). And they have no one with Hosung's systems depth.

Risk 3: Embedder Expands Into Debugging

Risk: Embedder could move from code generation into debugging assistance. Mitigation: Embedder's strength is datasheet parsing and code generation — very different technical problem from crash reproduction. More likely to become a partner than a competitor. Proactively build the integration.

Risk 4: Market Too Niche

Risk: Firmware debugging is a smaller market than horizontal AI tools. Mitigation: Memfault was acquired for $120M with ~$7.2M ARR and ~100 customers. There's clearly a business here. And we're addressing a higher-value problem (debugging > observability). If our average contract is 2x Memfault's ($64K vs $32K), we need fewer customers to build a meaningful company.

Risk 5: Enterprise Sales Cycle Too Long

Risk: Hardware companies are slow buyers. Regulated industries (automotive, medical) move even slower. Mitigation: Start with AI hardware startups (fast-moving, well-funded, Hosung's network). Use them as proof points for slower enterprise deals later.

11. YC Reapplication Strategy

The Story

"Every hardware engineer has driven to the office at midnight to debug a board. Hosung did it for 3 years at Nvidia. The tooling hasn't changed in 20 years — you still need a physical JTAG probe and a physical board.

Hosung built a way to reproduce hardware bugs in a virtual environment. No physical access needed. It works today for specific bugs. We're building the AI that makes it work for any bug, on any chip.

Embedder helps you write firmware. Memfault tells you it crashed. We tell you why — and let you fix it without touching the hardware."

What Changed Since Last Application

Last time (iri) This time
AI token management (same as Portkey/Helicone) AI firmware debugging (nobody doing this)
No founder-market fit Hosung = 3 years Nvidia systems engineer, the exact customer
No unique technical insight Working virtual debug reproduction technique
No moat Data flywheel (every bug trains the AI) + domain expertise barrier
2 beta teams, no revenue [Target: 5-10 teams, 2 paying by application time]

Key Metrics to Hit Before Applying

  • 5+ teams actively using the product
  • 2+ paying customers
  • 100+ bugs captured and analyzed
  • At least 2 chip architectures supported
  • Clear evidence of time saved (e.g., "debugged in 2 hours what normally takes 2 days")
  • Demo video showing full flow: device crash → AI analysis → virtual debug → fix

Appendix: What Happens to iri

Options:

  1. Open-source the proxy + CLI. Builds credibility in the developer community. The Rust proxy and CLI are genuinely good tech.
  2. Shelve it. No paying customers, no moat. Clean break.
  3. Keep the dashboard codebase. The Next.js dashboard, auth system, and team management features could be reused for the new product's web interface.

Recommendation: Option 3 — reuse the dashboard infrastructure, open-source the proxy if time permits. Don't spend more than a day on this. Focus forward.

Appendix: Naming

The new product needs a name that signals:

  • Hardware/firmware (not generic AI)
  • Debugging/diagnostics
  • Speed/remote access

Working name candidates:

  • probe — what you're replacing (the physical JTAG probe)
  • reTrace — replay + trace + "re" (reproduce)
  • phantom — debugging without the physical hardware (ghost of the device)
  • halflife — the decay of a hardware bug's time-to-resolution
  • spectra — analyzing the spectrum of a hardware failure

Pick one that feels right, or keep brainstorming. The name matters less than the product right now.