Abhishek Yogi

Featured Projects

Professional

Products shipped in role at Fareportal.

CheapOair AI Chatbot

0→1 → Gen AI rearchitecture · Owned end-to-end at Fareportal

The chatbot behind post-booking flight support at cheapoair.com, live today — owned end-to-end from a rule-based launch through a full rearchitecture into a multi-agent Gen AI system, as customers increasingly expected free-form, ChatGPT-style conversation.

Dialogflow ES chatbot → Gen AI chatbot (Vertex AI)

58% → 70%Engagement
48% → 53%Containment
62% → 80%CSAT
Visit live chatbot →
Show full case study Hide details

Problem

Call and email were the only support channels — expensive for the ~60% of bookings that are international, too slow for time-sensitive issues.

Approach

Launched on Dialogflow ES, then rearchitected onto Vertex AI as a multi-agent system (orchestrator + specialist agents) as users expected free-form, ChatGPT-style conversation.

Evaluation & rollout

Offline (golden/adversarial/regression) and online (LLM-as-judge) evals, cleared with Legal, InfoSec, and an AI committee before a staged 5% traffic rollout.

Ask the chatbot for more

Architecture details, functionality shipped, and the full Dialogflow → Gen AI migration story are one question away — try the chat icon.

Biggest challenge: developing prompt engineering mastery — the discipline the entire multi-agent system's reliability hinged on.

Dialogflow ESDialogflow CXVertex AIMulti-Agent OrchestrationLLM EvalsPrompt Engineering

Oli — AI Trip Planner

0→1 product strategy · phased launch · CheapOair (Fareportal)

A conversational, AI-powered trip-planning assistant embedded in the CheapOair mobile app — owned from problem framing and PRD through a phased launch roadmap. The vision: collapse destination discovery, flight search, itinerary planning, and personalized guidance into one journey-aware conversational interface, and make Oli the primary way travelers plan.

Outcome after end-to-end launch

+15%Engagement
65+Daily flight conversions
3Personas served
Show full case study Hide details

The bet, written down first

  • Problem — Travelers could only express intent through filters, and the product only worked for users who already knew their destination; there was no support for the "I don't know where to go yet" stage. Mid-funnel, the only way to get a question answered was to leave the flow and contact a human agent — killing momentum right before conversion.
  • Bet — If we replace filter-based search and forced human handoff with a conversational assistant that answers free-form destination and booking questions in context, users will explore more and convert at a higher rate than users who never engage with it — observable within each rollout stage.
  • Success criteria — CTR into Oli from its entry points; active engagement rather than open-and-abandon; positive ratings on suggested destinations and itineraries; ≥80% CSAT on per-message feedback; users acting on suggested flights; ≥20% conversion among users who engaged mid-flight-funnel, and ≥2% across everyone who interacted.
  • Evaluation — A gated rollout where two checks had to hold together at every stage: transcript audits confirming Oli was genuinely useful (not merely being clicked), and A/B metrics showing no cannibalization of app-wide CR and bookings. Either one failing was the kill signal; both holding was the signal to scale.

Who it's for — three planning mindsets

Explorer

"I don't know where to go." Wants inspiration, destination recommendations, and budget-driven ideas.

Planner

"I know where I want to go." Wants itinerary creation, recommendations, and comparison options.

Shopper

"I want the best flight." Wants flight discovery plus alternate-airport and alternate-date suggestions.

Approach

One conversational assistant personalized via geolocation, behavioral signals, and conversation memory — backed by competitive research across Trip.com and Mindtrip, and a month of UX iteration.

Execution

Coordinated 3 engineering pods (Chatbot, RPA, App) via daily syncs, grooming requirements and closing gaps as they surfaced.

Ask the chatbot for more

Feature-by-feature capabilities, the phased roadmap, and the full rollout story are one question away — try the chat icon.

North star: a personalized AI assistant that retains context, understands intent, and proactively guides every traveler throughout their journey — from first spark of inspiration to a booked trip.

Product StrategyPRDConversational AIPersonalizationRoadmappingVertex AICompetitive AnalysisCross-functional Execution

Priority Leads Tool

0→1 · Rules engine for Ops · Fareportal

A SQL-driven rules engine flagging high-risk leads — like users who'd repeatedly contacted support — for Ops to resolve before they escalated into complaints.

-8%Complaints
Show full case study Hide details

Problem

Support complaints were reactive — by the time a lead surfaced as a complaint, the pattern that predicted it had already repeated multiple times.

Approach

Codified rules with Ops leaders from real support patterns (e.g. 3+ contacts across call/email/chat) as SQL queries controlling lead generation in the CRM, each with its own SLA tracked via dashboards.

Outcome

Complaints down 8%. The system still runs today, fully automated, with no ongoing manual intervention.

Ask the chatbot for more

Rule design, SLA tracking, and how it plugged into the CRM are one question away — try the chat icon.

SQL Rules EngineCRM IntegrationOps PartnershipDashboarding

Assisted Selling

0→1 · Chat-assisted booking · Fareportal

Trigger-based chat launched directly on the flight listing page so travel experts could help users mid-booking-funnel, paired with Search Explorer's predictive flight filtering.

+40%Conversion (Search Explorer)
Show full case study Hide details

Problem

High-intent users were dropping off mid-funnel — idle on the listing page, comparing flights, or hitting no-results — with no way for an agent to step in before they left.

Approach

Identified and tested triggers (low conversion, idle customers, senior travelers, multi-city trips, sold-out cases), built rule-based routing to top-performing agents, and integrated with the agent booking engine so a single click carried the customer's exact search over.

Search Explorer

A companion feature using predictive filtering and value-focused tiles (e.g. "faster by 3hrs for $20 more") to guide users to better flights.

Ask the chatbot for more

Trigger logic, the UX experiments on the chat icon, and the A/B validation are one question away — try the chat icon.

Trigger-Based RoutingAgent Booking EnginePredictive FilteringA/B Testing

Curiosity Builds

Products designed, built, and shipped end-to-end for the joy of it.

Arthritis Companion

0→1 · Designed, built, and shipped end-to-end

A login-free daily companion for tracking arthritis symptoms and gentle exercises — designed around the arthritic hands of my mother (Maa), not a generic user persona. Grown into a clinical-grade tool with a body map, medication tracking, and a doctor-ready report.

Live demo → View source
Show full case study Hide details

Problem

Existing symptom trackers assume fine motor control: sliders, drag gestures, small tap targets, multi-step forms. For someone managing arthritis, the tool meant to help was itself hard to use.

Design constraints

Large tap targets, no sliders or drag gestures, voice-friendly notes, and a fixed bottom "Done" button reachable one-handed. No login, no account — every extra step is a barrier.

Approach

Local-first architecture: all data stored on-device via IndexedDB, no backend, exportable backups. An interactive body map for logging and visualizing symptoms, replacing flat checkbox lists.

Outcome

A daily companion that's grown into a clinical-grade tool — tracking medications, screening for patterns worth a doctor's attention, and generating a doctor-ready visit summary.

How I built it — vibe-coded, PM-led

No engineering team — I shipped this solo by vibe-coding with AI. My job was the product: framing the problem, setting the design constraints, making the calls on scope and UX, and reviewing every screen against my mother — the one person it was built for. AI coding tools turned those decisions into working, shipped code, and I iterated in tight loops — prototype, test on-device, refine — until it was something someone actually opens daily. The hard part wasn't the syntax; it was the product judgment about what to build and what to cut.

Body map

An interactive front-view silhouette (18 joints) for logging symptoms and visualizing which joints flare up most, sized for accessible, one-handed tapping.

Inflammatory signal screening

A conservative, non-diagnostic pattern check — recurring long morning stiffness with symmetric small-joint pain — that nudges a doctor visit without over-alerting on sparse data.

Medications & adherence

Full medication tracking with dosage, time slots, and daily dose logging, rolling up into an adherence rate.

Doctor report

A printable 30-day summary — pain and stiffness trends, top affected joints, adherence, and any flagged patterns — built to bring to a visit.

Skills this build demonstrates

Product JudgmentVibe CodingAI-Assisted Dev (Claude Code / Cursor)Rapid Prototyping0→1 ShippingUX for AccessibilityLocal-First PWAHealth Data Design

Ship Gate

0→1 · PM-operable AI eval harness · Designed, built, and shipped end-to-end

A tool that turns a product description or a batch of real production traces into a golden and adversarial test suite, runs it against a live conversational AI product, and returns a ship/hold verdict — including checking whether its own LLM judge can be trusted.

Live demo →
Show full case study Hide details

Problem

PMs shipping conversational AI usually eyeball a handful of replies and ship on vibes. Writing a real test suite means knowing which failure classes to look for; running it means waiting on an eng-built eval pipeline — so the check that matters most gets skipped.

Approach

Two paths into a suite: from real traces (read them, note what went wrong, cluster into failure modes, generate tests that target them) or from a written brief pre-launch. Tests run against any chatbot via a live endpoint, or a manual paste-the-reply mode for the hosted bots that block CORS.

Scoring

Deterministic assertions run first and are free; an LLM judge handles the fuzzy rubric only on what assertions can't decide. A judge-alignment panel then measures the judge's own hit rate and false-alarm rate against your own labels — reported separately, never averaged into one accuracy figure that would hide a judge that misses real failures.

Ask the chatbot for more

The prompt-injection defenses, the CORS constraint that forced two connection modes, and the judge-validation math are one question away — try the chat icon.

How I built it — vibe-coded, PM-led

Built solo in Claude Code, iterating the way the tool itself argues PMs should work: no PRD, a one-page bet written down first, then shipped and tested against real usage. Every version was QA'd end-to-end in a live browser before I trusted it — including catching a data-loss bug where a reload silently wiped hand-reviewed traces, and a disabled button that looked identical to an enabled one. The judgment calls were mine: what counts as a fair adversarial test, when a judge should be trusted, and when a "no API key" path is worth building versus a quality compromise not worth shipping.

Skills this build demonstrates

PM-Operable EvalsError Analysis (Open/Axial Coding)LLM-as-JudgeJudge Calibration (TPR/TNR)Prompt Injection DefenseVibe Coding (Claude Code)React / TypeScriptClient-Side Architecture

PM Job Radar

0→1 · Self-updating job-hunt system · Designed, built, and shipped end-to-end

A personal job-hunt system that surfaces fully-remote Product Manager & AI-PM roles I can actually apply to. Every weekday morning it sweeps ~30 job portals plus LinkedIn, keeps only roles posted in the last 48 hours and open to India-based applicants, verifies every link is a live posting, and ranks them freshest-first on one dashboard — with a daily email digest so a fresh opening never slips past.

How it cuts the noise

~30Portals swept daily
48hFreshness window
100%Links verified live
Live demo → View source
Show full case study Hide details

Problem

Job hunting means re-running the same searches across a dozen sites every day — and most "remote" listings are secretly on-site or already swamped with applicants by the time you find them.

Approach

One daily automation instead of five browser tabs: deep-paginate LinkedIn's guest API across keyword variants, pull remote boards and Indian portals, dedupe, and rank freshest-first — because a role posted an hour ago has far fewer applicants than one that's been up two weeks.

The catch I designed around

Job boards lie about "remote" — LinkedIn's own remote filter returned explicitly on-site roles. So the system opens each posting to confirm the workplace type and that the link is live before it ever shows up, and flags anything it can't confirm rather than hiding it.

Daily delivery

A scheduled cloud agent runs at 8am IST and a Google Apps Script emails the fresh roles straight to my inbox — dashboard, morning digest, and email all kept in sync.

How I built it — vibe-coded, PM-led

Built solo with Claude Code. The engineering was the easy part; the product judgment was the work — deciding that freshness is the real edge, that an unverified link is worse than no link, and that an honest "couldn't confirm remote" beats a confident wrong answer. I drove the scraping tactics (paginate the guest API, distrust the "remote" filter, verify each posting), the ranking, and every trust rule, then iterated in tight loops against real live listings.

Biggest challenge: trusting the data — designing the verification so a dead link or a mislabeled on-site role never reaches the final list.

Skills this build demonstrates

Product JudgmentAutomation (Cron / Apps Script)Web ScrapingLinkedIn Guest APIData VerificationFreshness RankingVibe Coding (Claude Code)Client-Side Dashboard

Plant Protector & Guide

0→1 · Designed, built, and shipped end-to-end

A photo-diagnosis tool for home gardens, built around my family's garden in Bina, MP — snap a leaf and get a diagnosis with home remedies tuned to the local climate and season. Bring-your-own API key, no backend, no subscription.

Live demo →
Show full case study Hide details

Problem

Farm-diagnosis tools target industrial agriculture, and generic plant-ID apps name a species but don't say what's wrong or what to do about it — and none of them know Bina's climate.

Approach

Photo diagnosis through Claude's vision API, a seasonal guide tuned to the local Sagar-district climate, and a plant journal that tracks each scan's health status over time.

Design constraints

No login, no subscription, no backend — the journal lives entirely on-device, and the visitor supplies their own Anthropic API key so the tool costs nothing to run.

Ask the chatbot for more

The diagnosis prompt design, the seasonal-guide data, and the BYOK flow are one question away — try the chat icon.

How I built it — vibe-coded, PM-led

No engineering team — I shipped this solo by vibe-coding with AI, the same way I built the Arthritis Companion. My job was the product: choosing what "diagnosis" should actually return to someone standing in their garden, tuning the seasonal guide to a specific place instead of a generic climate zone, and deciding that bring-your-own-key was worth the extra setup step in exchange for a tool that costs nothing to keep running.

Skills this build demonstrates

Vision AI (Claude)Prompt EngineeringLocal-First ArchitectureBYOK DesignSeasonal PersonalizationVibe Coding (Claude Code)

Ledger

0→1 · Cross-platform finance app · Private beta, not yet public

A cross-platform net-worth and budgeting app for couples — offline-first, with per-account privacy so a partner never sees an account marked private, at any level. Currently in private development-build testing on iOS and Android.

Show full case study Hide details

Problem

Shared finances break most budgeting apps: either everything is visible to both partners, or nothing is shared and net worth becomes impossible to see honestly. Multi-currency accounts, market-linked mutual funds and equities, and offline usage add edges most personal finance apps don't handle well.

Approach

One shared ledger with per-account visibility (private / shared) enforced at the database level with row-level security, not just a UI toggle. Money is always stored as integer minor units, never floats, so nothing rounds wrong.

Data & sync

Offline-first: every synced table carries a sync envelope (revision, device ID, soft-delete) so edits made on two phones without connectivity resolve correctly once they sync. Market data is pulled server-side on a schedule, never fetched from the client.

Ask the chatbot for more

The couple-mode privacy model, the offline sync design, and the money-handling rules are one question away — try the chat icon.

How I built it — vibe-coded, PM-led

Built solo with Claude Code on an Expo/React Native + Supabase stack, chosen to get a real financial product's hard edges right before writing a single feature screen — the money model, the offline sync engine, and the privacy rules, tested against a two-device airplane-mode scenario before any UI existed. The judgment calls were mine: what "private" has to mean in a shared household ledger, which financial values are safe to cache versus must always be recomputed, and which vendor data is trustworthy enough to show a number next to.

Skills this build demonstrates

Offline-First SyncRow-Level SecurityReact Native / ExpoSupabaseFinancial Data ModelingMulti-CurrencyVibe Coding (Claude Code)

PM Case Lab

0→1 · Daily case-study practice tool · Designed, built, and shipped end-to-end

A personal PM interview trainer: one real-world product case in my inbox every morning — grounded in actual company decisions, not invented scenarios — plus a practice site with a 45-minute timer, a self-scoring rubric, a 75-question behavioural bank, and a story library pulled from my own work history. Built around published interview frameworks, with two more I wrote myself for case types those frameworks don't cover.

What's in the library

159Real-world cases
4Interview frameworks
75Behavioural questions
Live demo → View source
Show full case study Hide details

Problem

Most interview prep is either a book of generic prompts with no rubric, or a paid mock-interview service. I wanted daily reps against real company decisions, scored against the same dimensions an actual interviewer uses — and a way to turn my own work history into behavioural-interview stories instead of improvising them cold.

The frameworks

Product Sense and Analytical Thinking come from Lenny's Newsletter's published interview guides. Root-cause analysis and AI-product cases have no equivalent published framework, so I wrote both myself — a 7-step RCA structure and a 7-stage AI-product structure whose signature move is that "don't build this as AI" is a valid, scored answer, not a cop-out.

Zero infrastructure, by design

No server, no API key, no LLM at runtime. The library is static JSON; "today's case" is a pure function of the date, computed identically in the browser and in a small Google Apps Script — so the site and the daily email can never disagree about which case today is, and nothing can go down except GitHub Pages or Gmail.

Stories from my own history

My "Experience in Detail" doc — dense prose, not interview-shaped — got converted into 14 structured STAR stories, each anchored to a verbatim quote from the source so nothing got paraphrased into something I didn't actually do. A coverage map cross-references them against the 75 behavioural questions and flags the themes with no story yet as "stories to write," instead of leaving a silent gap.

How I built it — vibe-coded, PM-led

Built solo with Claude Code, planned with Opus and implemented with Sonnet. The product judgment was deciding what a good case actually teaches — every case anchors to a real, publicly verifiable company decision, and any number that isn't public is explicitly tagged as an interviewer assumption rather than presented as fact, so studying the library never means memorizing an invented metric. I drove the framework design, the fact-verifiability rule, the day-selection architecture, and the site's status-tracking model, then iterated against the built library and a full local click-through before publishing.

Biggest challenge: keeping 159 cases factually honest — every case had to separate what a company actually, verifiably did from what the exercise merely assumes for the sake of the drill.

Skills this build demonstrates

Product JudgmentInterview Framework DesignContent ArchitectureGoogle Apps ScriptClient-Side StateVibe Coding (Claude Code)Opus-Plan / Sonnet-Build