Lucky
Bajaj

Working in insurance at ThoughtWorks sparked a question: how are consumer-facing insurance platforms solving the same fundamental problem — getting people to buy insurance — through radically different product philosophies? I mapped three players who represent three distinct bets on how insurance distribution should work in India.

This teardown examines PhonePe (super-app, transaction-first), PolicyBazaar (comparison marketplace), and Ditto (advisory-first) — across UX, strategy, business model, and user journey depth.

Click each platform to explore their user journey:

PhonePe: Low CAC (organic from payments app) + high volume + recurring AutoPay premiums. First-year commission (~₹16K on ₹52K premium) pays for acquisition. Trail commissions (years 2–30) are near-pure profit. Cross-sell funnel: insurance → investments → loans.

PolicyBazaar: Moderate CAC (performance marketing) + conversion optimization via upsells. "Limited Pay" upsell doubles premium (₹1,350 → ₹2,786) with higher commission. Add-ons (spouse cover: +₹567/mo) inflate average transaction value. Scale through paid acquisition.

Ditto: High CAC (advisor call costs ~₹500–1,000) + premium customer required. Economics only work if: customers buy ₹5Cr+ sum assured policies, claims success drives referrals, and lifetime support justifies positioning. This is a relationship business, not a transaction business.

Nutrition labels are information-heavy but decision-poor. Consumers face a wall of numbers — calories, macros, ingredient lists — with no clear signal on whether a product is suitable for them. The gap isn't data; it's interpretation. Even health-conscious shoppers hesitate at the shelf because translating nutritional data into a personal judgement call requires knowledge most people don't have.

Smart Food Label Checker uses computer vision + AI reasoning to extract nutritional data from a label photo and deliver a structured health verdict in under 5 seconds.

Prompt-based scoring over rigid rules: Rather than fixed thresholds (e.g. "sugar > 10g = bad"), the product uses AI-guided reasoning — enabling nuanced trade-offs like high fat but high protein in a nut bar. This sacrifices some consistency for realistic, contextual judgement.

Mobile-first, minimal inputs: Deliberate choice to require zero mandatory inputs at launch. Personalization is opt-in. This reduces friction at first use, with the tradeoff of less tailored early scores — acceptable given the discovery goal.

Category-awareness over universal scoring: A 5g sugar biscuit is very different from a 5g sugar fruit — context-aware judgement prevents misleading verdicts, though it adds prompt complexity.

• Phase 1 (MVP): Image upload → AI extraction → health score + verdict display
• Phase 2: Barcode scanning, alternative product suggestions
• Phase 3: Grocery basket health analysis, dietary pattern tracking
• Phase 4: Integration with fitness apps (MyFitnessPal, Apple Health)

My Powai ↔ Andheri commute varied by 30–40 minutes depending on departure time, yet every decision was based on intuition. Without historical data, it was impossible to distinguish real traffic patterns from perceived randomness — and every suboptimal departure meant avoidable time lost.

"If I collect enough timestamped travel duration data across different departure windows, I can identify statistically reliable patterns that reveal an optimal departure window — reducing average commute time without changing the route."

• Traffic variability is quantifiable: Duration swings were larger and more predictable than intuition suggested
• Directionality matters: Powai→Andheri and Andheri→Powai have meaningfully different congestion fingerprints by hour
• Small datasets mislead: Early patterns required weeks of validation before acting — a core PM lesson about premature conclusions
• Automation removes behavioural bias: Scheduled collection removes the human tendency to only check when it feels convenient

• Phase 1 (Done): Automated logging pipeline + historical CSV dataset
• Phase 2: Interactive dashboard (Streamlit or similar) replacing manual CSV review
• Phase 3: Predictive model with confidence intervals per departure window
• Phase 4: "Best time to leave" push alert with weather & event signal enrichment

Every lunch and dinner is a 10–45 minute lean-back window. People want something good on screen — but every platform they open is optimised for binge sessions, not meal-sized viewing. The result: endless scrolling, defaulting to the same rewatch, or giving up entirely.

The gap isn't content quality — it's discovery under time pressure. Nobody can recall what they'd actually enjoy when the food is getting cold and decision fatigue kicks in. Availability beats preference every time.

Ran a structured survey on LinkedIn targeting urban professionals who eat alone regularly.

MealTime is a recommendation layer — not a streaming platform. It sits on top of YouTube and existing OTT apps, surfacing exactly 5 picks per meal session.

Two-mode dynamic weight system. In "For you" mode, taste vector drives 33% of the score — the biggest single factor. When a specific mood is active, mood fit jumps to 48% and taste drops to 12%.

Mood filtering is tag-based, not genre-based. Each content piece is scored 0–100 for mood fit using boost/penalty tag lists. A funny Drama surfaces in laugh mode. A boring Comedy sinks. Genre is a tiebreaker, not a gate.

Duration uses an asymmetric Gaussian curve — short content is penalised gently (you can watch another one), long content penalised harder (you can't finish it).

Hindi (69) · English (89) · Bilingual (16). All hand-curated with quality scores, tags, and search-intent URLs.

Tag-based mood filtering over genre exclusion: The original approach excluded entire genres per mood (all Drama blocked in laugh mode). This created false negatives — funny Dramas hidden, unfunny Travel content showing. Switching to per-item tag scoring fixed accuracy without losing the mood constraint.

Dynamic weight allocation: A user's taste profile and their current mood can conflict. When mood is active, it takes 48% of the score so it can't be overridden by taste. In "For you" mode, taste gets 33%. Clean separation, no contradictions.

BYOK AI model: Claude API adds personalised reason lines and smarter taste profiling. But the app works fully without it — hardcoded scoring is the default. AI is an enhancement layer, not a dependency. Cost: less than ₹1 per session.

Search-intent URLs over deep links: Instead of direct platform links (which break when content moves), every recommendation links to a YouTube or Google search for that specific title. Slightly more friction, zero broken links.

• Phase 1 (Shipped): Onboarding, scoring engine, mood filtering, feedback loop, AI mode, 200 content pieces
• Phase 2: YouTube Data API integration, content thumbnails, couple/shared screen mode
• Phase 3: 500+ content pieces, proactive meal-time notifications, native app

Multi-agent AI systems sound complex, and the ecosystem makes them feel that way. Frameworks like LangChain, CrewAI, and AutoGen add abstraction layers that obscure a simple truth: a multi-agent pipeline is just prompt files, a shell script, and the filesystem. Developers who want to experiment face two options: learn a complex framework, or figure out the orchestration pattern from scratch. Both slow you down before you've started on the actual problem.

After studying real-world multi-agent systems (including viral examples like autonomous stock portfolio managers running 30+ agents in parallel), I noticed the underlying pattern is always the same:

• Agents = Claude Code sessions with specific instructions (prompt files)
• Orchestrator = A bash script running agents in sequence or parallel
• Communication = Agents read/write files, the filesystem is the message bus
• Scheduling = Cron or GitHub Actions triggers the whole thing autonomously

If the pattern is this consistent, it should be scaffoldable. That's what Agent Forge does.

my-pipeline/
├── CLAUDE.md              # Shared context every agent reads
├── README.md              # How to run and customize
├── prompts/               # One .md file per agent
│   ├── 01-data-collector.md
│   ├── 02-analyzer.md
│   ├── 03a-bull-case.md   # Parallel agents use letter suffix
│   ├── 03b-bear-case.md
│   └── 04-report-gen.md
├── scripts/
│   ├── run-pipeline.sh    # Orchestrator
│   └── schedule.yml       # GitHub Actions cron config
├── config/
│   └── pipeline.json      # Pipeline parameters
├── data/                  # Agents communicate through files
└── output/                # Final deliverables

No framework, by design. The orchestrator is a bash script. Agents are markdown prompt files. Communication is the filesystem. Complexity kills adoption. Anyone who can write a prompt can build a multi-agent system.

Files as the message bus. One agent writes JSON, the next reads it. No databases, no queues. Every agent is independently testable.

Interactive scaffolding over static templates. The skill asks about your specific use case and generates custom prompt content, not blank templates.

Parallel support built in. The orchestrator handles sequential and parallel execution with proper process management and failure detection.