A real PRD example: planning a daily dashboard I built with an AI agent

Every morning I used to spend 20 to 30 minutes checking five apps before leaving home: the weather, Google Maps for traffic, social media, email newsletters and Feedly for news. I wanted one page that shows what I need for the day in one quick look.

What is a PRD?

Before building anything, I wrote a short plan, the same way I would as a Product Manager: what the page is for, who it’s for and how I’d know it worked. That’s called a product requirements document (PRD). Then I built the page with an AI agent, one step at a time, and updated the PRD as I went. You can see it at rachitrohan.com/daily. It went live on October 8. This post covers the first five days, through October 12.

The first six sections are the plan. The last two cover what shipped and what I’m still deciding.

1. Goals and success measures

The goal: know what I need for the day at a glance, on my phone or at my desk. The page covers:

• Weather
• Transit and traffic
• The news I follow, collected and filtered
• What’s happening in Toronto

It also has to work on a phone and a laptop, with a few simple settings so other people can use it too.

Success measures, and where I am today:

• My morning check takes 10 minutes or less, down from 20 to 30. Today it takes 5 to 10.
• The page opens in under half a second. Today it loads in just under half a second.
• No cookies or trackers. None, checked at every launch.
• Upkeep stays at 30 minutes a week or less. In the first week it’s been about 30 minutes.

2. Background and assumptions

• I started this site in 2013 to own my domain. This year I’m rebuilding it with an AI agent.
• I had a Daily page for years, made of embedded widgets: a weather box, a traffic map and a stock ticker. They broke often, and I couldn’t fix them without code.

What I assumed going in:

• I can rebuild my site with limited coding knowledge by working with an AI agent.
• Free public sources, like open data and news feeds, are enough for a useful page.
• One page can work well on a phone and a desktop.
• The page will be useful every day, as a quick look on my phone or a live page on a second monitor.

3. User stories

• As a mobile reader (me), I want a quick look at the weather, transit and news, so I’m informed without opening five apps.
  Done when: the At a glance card shows the weather, my transit lines and the top news at the top of the page, and the page loads in under half a second.
• As a laptop reader (me), I want a page that updates itself with news, weather and events, so I can scan it through the day.
  Done when: the page refreshes on its own and shows when it last updated.
• As a visitor in Toronto, I want to hide the boxes I don’t need and pick my own transit lines, so the page fits my morning.
  Done when: my choices stay in my own browser, with no account and no cookies.
• As a commuter underground (me), I want the page to open without a connection, so I can still check it on the subway.
  Done when: the home screen app shows the last copy with its time.

I haven’t tracked who else uses it, so the visitor story is still a guess.

4. User interaction and design

• First view: a new visitor can tell what the page is for right away.
• At a glance: a card at the top on my phone, then short boxes that are easy to scroll, and a band across the top on a laptop.
• Boxes: every box can collapse, move, hide or go wide. On phones you can also pin one.
• A dark theme with one accent colour, and text that passes accessibility contrast.

5. Decisions and non-goals

• No cookies, trackers or cookie banner. Layout choices, and what you saw on your last visit, stay in your own browser.
• Big new features go to a private preview page first, and go live only after I check them.
• No general world or tech headlines, because word filters can’t keep them neutral. I follow a few newsletters I trust instead. The one exception is AI stories from two tech news sites.
• No stock market numbers, because that data is licensed.
• I left government news out at first because it was mostly ministers’ announcements. I added it later with strict filters.
• No heavy design, extra plugins, paid feeds, social sharing or growth tactics.
• Some headlines link to paywalled sites, and the page marks them.

6. Risks

• A source goes down: every source keeps its last good copy, so one broken feed never breaks the page.
• Terms and licensing: I show only titles, times and links, and leave out data that needs a licence.
• One person keeping it running: a monthly health check flags broken feeds.

7. What shipped, and what changed after launch

I built things in the order I check them each morning:

• October 8: weather and three news boxes
• October 9: transit and traffic, a Latest box, and game times for the Leafs, Raptors and Jays
• October 11: Toronto events, an At a glance card for phones, a home-screen app that works offline, and more ways to customize the page (hide, pin and widen boxes, pick your transit lines)
• The same night: concerts, local tech meetups and a government news box
• October 12: an At a glance band for laptops, a live clock, an evening mode that switches to tomorrow after 8 pm, and a short “Since you looked” list of what changed since my last visit

One change I reversed: Latest first cycled through the newest stories. I kept missing headlines while they turned, so now it’s a fixed list of the 8 newest.

Two things surprised me:

• The City’s events list is one very large file with 26,809 listings. Early each morning my site reads it in small pieces and keeps only the next 10 days.
• I had the agent audit the code, and refreshing all the sources went from 6.5 seconds to under 3.

8. Open questions, and my answers so far

• How much is too much? When I stop reading a box, it’s time to cut it. From now on, a new box should replace one I’ve stopped reading.
• Just a daily page, or more? For now it’s one page. If I find I only want one box, it gets its own page.
• Should AI pick my news? I priced it: an AI filter and a short daily brief would cost about a dollar a month. I chose a simpler idea first, a “Since you looked” list of what changed. AI can come later if the word filters keep missing stories.

What I learned

• Free public data was enough. Weather, transit, City of Toronto events and news all come from free feeds.
• The agent builds fast, so most of my time went to deciding what to build and checking what it built.
• Scope grows fast with an agent. I added more than a dozen features in five days.
• Test on real data before shipping. I ran every filter change against live news first, which caught stories that would have slipped through.
• Even with an AI agent doing the building, nothing went live without a preview, my OK and a check afterwards.

Use this as a template

If you want to write your own PRD, these are the eight sections I used:

1. Goals and success measures
2. Background and assumptions
3. User stories, each with a “Done when”
4. User interaction and design
5. Decisions and non-goals
6. Risks
7. What shipped, and what changed after launch
8. Open questions, and my answers so far