Hi, I'mShivank

Spotted

• ·My browser had too many open tabs, and I couldn't keep track of them.

Built

• ·A Chrome extension that auto-groups open tabs into meaningful groups and finds the duplicates, for one window or every window at once.
• ·The toolbar badge shows how many duplicates are open; one command closes them, keeping one of each.

Learned

• ·Suggest, don't impose: it proposes groups you can review, rename or uncheck before anything moves. People trust an organiser they can overrule.

Spotted

• ·We often find it difficult to think of what to eat at home, especially if you're into fitness and tracking your protein.
• ·The problem is more prevalent in shared households with working professionals with limited time, in a country like India with different cuisine tastes, different preferences (veg/non veg), especially when it is super easy to choose the quicker option from Swiggy/Zomato.

Built

• ·Understood psychology and behaviour behind how people in Bangalore order among family, friends, and a voluntary focus group.
• ·Validated that the problem exists.
• ·Built and iterated on a meal planning and fitness application powered by AI (currently at v4).

Learned

• ·Learnt to build an app from scratch in 2 weeks (with AI tools of course).
• ·Humbled by the feedback, picked up and iterated to solve a real problem.
• ·Being used at my home now and soon to release on the app store (verification pending).

Next steps

• ·GTM and sell.

Spotted

• ·The weekly metrics deck was a manual Tuesday ritual.
• ·The daily check ran as a scheduled task on my laptop that kept failing for reasons unrelated to data: the machine asleep, a shell command hanging the run, one stuck run blocking every run behind it.

Built

• ·Every morning, an agent rebuilds ~20 dashboard charts from the raw event APIs — which also yields day-over-day and week-over-week comparisons the dashboard can't show — and ships a digest marking each funnel step healthy, at risk or no data, flagging any rate that fell more than 10 points overnight.
• ·Every Tuesday, a second agent runs two dozen queries for the week just ended, computes week-on-week deltas, renders and files a deck, and emails headline approval rates by funnel stage and segment.

Learned

• ·Verify, don't trust: every rebuilt figure must reproduce the dashboard exactly, to the unit, and the deck is checked for empty, clipped or stale cells before it goes anywhere.
• ·Ship the gap, not the guess: a chart that doesn't reconcile is dropped and annotated with both numbers. Eighteen of twenty metrics beats none; a silent mismatch beats neither.
• ·Fires four times, sends once: each scheduled run checks Sent Items first, so transient failures self-heal and nobody gets the deck twice.
• ·Push, don't log: nobody reads a transcript, so outcomes and failures arrive as a phone notification.

Spotted

• ·Writing PRDs is slow, and every PM writes them slightly differently.

Built

• ·You give it three things: the requirements document, the feature area the PRD covers, and any background or constraints it should know.
• ·It returns a complete PRD in the standard template — same structure every time — ready for stakeholder review.

Learned

• ·Grounded, not generated: requirements carry inline labels — [From RD], [From KB] — so a reviewer can check any line without asking where it came from.
• ·Where the requirements are silent, it pulls context from the internal knowledge base, but never adds scope they didn't define. Context, not invention.
• ·What it can't answer, it flags under Open Questions with a suggested next step, so gaps surface before review instead of in it.

Spotted

• ·PMs, engineers and business stakeholders all need the same answers — how a flow behaves, what a requirement said, why a decision was made — and all were digging through sprawling docs to find them.

Built

• ·Now they ask, and get an answer with a citation attached.
• ·Every response ends with Sources Used, pointing at the exact document, ticket or page — and the section within it — so the answer can be checked rather than trusted.

Learned

• ·Three sources in strict priority order — PRDs, then the engineering board, then a narrow set of wiki pages — resolve contradictions instead of averaging them.
• ·A scope it refuses to leave: a confidently wrong answer about how a credit-card flow behaves is worse than no answer.
• ·"I don't know" is a valid answer, with a pointer to the person or team to ask. That turns out to be the feature people trust it for.

Spotted

• ·A PM's loop starts with discovery, and part of that is understanding the fintech market and what it means for a credit card business.

Built

• ·A short email digest for myself and a couple of colleagues: a box of key highlights, then a handful of short stories — each with the date, the number that matters, one line on why it matters for payments or banking infrastructure, and a link to the primary source.
• ·Nobody writes it. A scheduled Claude agent researches the week, verifies every claim against a primary source, writes and sends the issue, then checks the Sent folder to confirm delivery.

Learned

• ·A coverage log means nothing repeats: a story only returns on material change, like a pilot going live or a regulator stepping in.
• ·Strict editorial rules: optimise for newness, not coverage. No hype words, pilots never presented as launches, vendor numbers labelled as vendor numbers, and a quiet week gets a shorter issue.
• ·Giving an agent a real editorial job — with guardrails, memory and a feedback loop — works better than asking it to summarise the news.