Build a 5-minute verbal diary with AI

Some days feel full from beginning to end. Then Friday arrives and the whole week feels like a blur.

By Vanessa Duncan-Andrade

The exact prompts to capture the moments that matter

Some days feel full from beginning to end. Then Friday arrives and the whole week feels like a blur.

I wanted to test a simple place where I could talk for 5 minutes, notice the small details, and get a quick reflection at the end of the week. I built the first version after seeing Allie K. Miller share a daily brain-dump tool she made in Claude Code.

My version adds prompts for work, how the day felt, and moments with people you love that are easy to overlook inside the logistics. You can change every question so the dashboard fits your actual life.

A quick, honest note before you build

This guide gives you tested instructions, privacy-minded defaults, fallback options, and a checklist for catching common problems. It cannot promise that every build will work perfectly on every AI coding tool, browser, phone, calendar, or hosting service. Those products, permissions, and generated code can behave differently or change over time.

Use fake information while building and complete every Version 1 test before adding personal entries. If a test fails, stop and fix it before continuing. This first version is a personal-use experiment, not a security-certified diary service, medical record, or guaranteed backup. Export anything you care about, and do not use it for highly sensitive or confidential information.

What “phone-ready” actually means

A link beginning with 127.0.0.1, localhost, or file:// opens only on the device running the project. It is not a phone link.

Version 1A may give you a temporary same-Wi-Fi address for testing on your phone. That address works only while the computer and local server are running, and ordinary HTTP can block microphone features. The app becomes reliably phone-accessible in Version 1B, when it has a stable HTTPS address that you open and test on your physical phone.

If phone access is your goal, complete both Version 1A and Version 1B. Do not stop after receiving a local preview URL.

Start small: this is exactly where Version 1 ends

Build this in 2 versions.

Version 1: one device, browser storage

Version 1 has 2 steps:

Version 1A: Build and test the live preview with fake entries.
Version 1B: Give it a stable HTTPS address, keep the diary data on one device, and add it to your phone or computer home screen.

Version 1 is finished when the checklist after Prompt 1B passes. Stop there and use it for a week. It is a personal-use version for one person on one chosen device. It is not a service for collecting or storing other people’s diary entries.

At that point, you will have:

A stable dashboard you can reopen on one chosen device
Daily text input plus optional speech input
Editable entries saved in that device’s browser
A weekly view based on your real saved entries
A recurring calendar reminder
Export and delete controls

Version 2: accounts, syncing, and push reminders

Version 2 is optional. It adds a database, an account, syncing across devices, and a notification service. That version carries more privacy, security, cost, and maintenance decisions.

Build Version 1 first. The Version 2 section is planning material for later.

What you need

Use an AI coding tool that can create files and open a live website preview. Claude Code, Codex, or a browser-based AI app builder can do this type of work. A standard chat window may stop after writing the code, which leaves you staring at a file instead of the dashboard.

You do not need to write code yourself. You will need to paste prompts, answer setup questions, open a live preview, click through the tests, and ask the builder to fix anything that fails. Expect a guided build with several testing steps.

For microphone access on a phone, the finished app usually needs an HTTPS address. A local preview may work on the computer running it and still block the microphone when opened from a phone.

Choose the starting point that feels right

Start with your phone today

If an AI coding tool feels like too much right now, start the habit before building the dashboard:

Create a daily calendar reminder called “Take 5 minutes for today’s moments.”
Use your phone’s voice-recorder or notes app to talk or type for 5 minutes.
Put the date at the beginning and keep the entries together in one folder.
Review that folder once a week and notice what mattered.

Check whether your chosen app syncs recordings or notes to a cloud account. Its privacy and storage settings are separate from this guide.

Build the dashboard with AI

Choose this route when you are comfortable following an AI builder through setup and testing. The builder writes the code, but you are still responsible for viewing the live app, clicking every control, and completing the checklist with fake information. You can return to this route after using the simple phone version for a few days.

Before adding anything personal

Use fake details until Version 1 passes its tests. Then confirm:

You know whether the preview or final URL is public, private, unlisted, or temporary.
The app says where entries are stored.
No analytics or outside database was added.
You understand the speech-recognition privacy notice.
Export works and you know where the exported file was downloaded.
You reviewed every code change before redeploying the app.

Local browser storage separates data by website address. It is still stored inside your browser profile. It is not automatically encrypted by this app, and it can be deleted if you clear site data, use private browsing, lose the device, or the browser removes stored data.

Any JavaScript later served from the same website address can potentially read that site’s browser storage. Use a hosting account you control, avoid unreviewed automatic deployments, and review changes before updating the live app.

Version 1A: build and test the preview

Open a new, blank project in your AI coding tool.
Paste Prompt 1A below.
Answer the 5 setup questions.
Let the tool build and run the preview.
If it gives you code without opening the dashboard, paste this exact line:

Start the app, open the live visual preview, and give me the exact URL. If my first device is a phone, do not give me 127.0.0.1, localhost, or a file:// link as phone access. When possible, bind the temporary server to the local network and give me the same-Wi-Fi address. Label it temporary and explain that microphone access may require HTTPS. Tell me whether every URL is temporary, public, private, or unlisted. Do not publish anything without asking me first.

Prompt 1A: Build the preview

Copy everything inside the prompt box.

You are my product designer and software engineer. Build and run a working preview of a gentle,
5-minute verbal-diary web app. Do not stop at a plan, wireframe, or code sample.

First ask me these 5 questions in one message:

1. App name
2. Main color
3. Daily check-in time
4. Prompt topics: work, loved ones, wins, hard moments, or all
5. First device and browser: phone or computer

If I say “choose for me,” use: Today, out loud; calm purple on warm cream; 8:30 PM; all topics; phone.

SCOPE

This is Version 1A for one person on one device. Use a small static HTML/CSS/JavaScript app or the
fewest dependencies possible. If a package or build fails, fall back to a zero-dependency static app.
Do not add accounts, cloud storage, syncing, analytics, ads, push services, API keys, paid services, or
deployment.

BUILD 3 SCREENS

TODAY

- Show the date, “A few minutes for what mattered today,” and one editable rotating prompt.
- Starter prompts:
  1. What happened today that felt meaningful?
  2. How did today feel underneath the logistics?
  3. Did a loved one say or do something that made you smile, pause, or feel connected?
  4. What felt hard today? What helped?
  5. What tiny moment felt worth noticing?
- Always provide an editable text area.
- Add optional speech input when supported. Before first use, show: “Speech recognition may be
  processed by your browser or its speech provider. Use typing if you want to keep this entry out of
  speech services.”
- Request permission only after a tap. Typing must still work if speech is unavailable, denied, or
  fails. Never erase existing text after a speech error and never describe speech as local unless the
  browser confirms on-device processing.
- Let me choose Light, Steady, Tired, or Heavy and save the entry.

YOUR WEEK

- Use only real saved entries to show this week's check-in count, most common mood, up to 3 short
  moments, and a dated timeline. Do not invent an AI summary.

REMINDER

- Save a chosen time and download a daily RFC 5545 .ics event titled “Take 5 minutes for today's
  moments.”
- Use a floating local DTSTART in YYYYMMDDTHHMMSS format without Z or TZID, plus unique UID, DTSTAMP,
  RRULE:FREQ=DAILY, and DISPLAY VALARM containing ACTION:DISPLAY, TRIGGER:PT0S, and DESCRIPTION.
- Use valid CRLF line endings and escaped iCalendar text. Explain that I must import it, allow calendar
  alerts, and verify the first reminder.

PRIVACY AND RELIABILITY

- Save entries in IndexedDB for this website origin; request persistent storage when supported without
  promising permanent storage.
- Store transcript text, not raw audio. Send no diary data to APIs, databases, URLs, logs, analytics,
  trackers, remote fonts, or unnecessary third-party scripts.
- Add JSON and readable text exports. Warn that exports are ordinary unencrypted files.
- Add confirmed “Delete all entries.” Explain that browser data can be removed and that later
  JavaScript served from this same origin could read its IndexedDB.
- Use fake, clearly labeled sample entries only. Seed them once, tracked separately from whether the
  entry store is empty. After “Delete all entries,” examples must stay deleted after refresh and reopen.

DESIGN AND DELIVERY

- Make it calm, warm, accessible, and mobile-first with no black background. Use a bottom phone
  navigation, large tap targets, visible keyboard focus, phone safe-area spacing, and no horizontal
  scrolling at 390x844 or 360 pixels wide.
- Keep computer navigation visible near the top without requiring a scroll through page content. Place
  it before the main content in the DOM when needed; do not rely only on CSS positioning.
- Every dialog or modal must be closed on first load. Ensure component styles do not override the HTML
  hidden state, and test opening, closing, canceling, and confirming each dialog.
- Every visible control must work. Handle an empty diary, long text, refresh after saving, and denied or
  unavailable speech.
- Run and open the visual preview. Give me its exact URL and say whether it is temporary, public,
  private, or unlisted; where entries are stored; every outside request or dependency; and anything you
  could not test. If a local development server is running, explain that the URL works only while the
  server is running and tell me exactly how to stop and restart it. If the first device is a phone,
  never present `127.0.0.1`, `localhost`, or `file://` as a phone-accessible link. When possible, bind
  the temporary server to the local network and provide the same-Wi-Fi address. Do not publish without
  asking me first.

If the tool starts a local server “in the background,” that is still a temporary preview. It may stop when the process ends or the computer restarts. It is not the stable Version 1B app.

Test Version 1A with fake information

The prompt itself does not receive a passing grade. The finished app does. A beautifully written prompt can still produce different results in different tools, so do not skip this section.

Deny the microphone and confirm that typing still works.
Allow the microphone and read the speech privacy notice before saying anything.
Save an entry, refresh the page, and confirm that the entry remains.
Confirm that no dialog is open when the page first loads. Open, cancel, close, and confirm each one.
Open the weekly view and confirm that it uses the entry you saved.
Change the reminder time.
Download and import the calendar file. Verify its local time, daily recurrence, and alert.
Export your entries and open both downloaded files.
Find “Delete all entries,” choose it, and cancel.
Delete all entries, refresh and reopen the app, and confirm that example entries do not return.
Try the dashboard at 390 by 844 pixels and at 360 pixels wide.
Choose the computer layout and confirm that its navigation is visible without scrolling through the Today page first.
Confirm that the tool disclosed the URL’s access and expiration status.
If your first device is a phone, confirm that the phone opens the temporary same-Wi-Fi link. A 127.0.0.1, localhost, or file:// link does not pass this test.

Three regression bugs caught in a real Prompt 1A build

A test run in Claude Code caught three problems that looked reasonable in the source code:

CSS overrode the browser’s hidden state, so every modal appeared at once.
Computer navigation was placed after the Today content and landed below the fold.
Deleting everything made the fake examples return on the next visit because the app seeded examples whenever the entry store was empty.

This is why you must view the live preview, click every control, delete test data, refresh, and check both the phone and computer layouts. Code review alone did not reveal these problems.

Then paste this separate audit prompt:

Audit Version 1A before adding anything new. Use fake data. Test every visible control, empty and long
entries, saving plus refresh, the real weekly calculations, denied and unavailable speech, both export
files, delete cancellation and confirmation, the .ics contents, and layouts at 390x844, 360 pixels
wide, and computer width. Inspect the app for outside requests, trackers, diary text in URLs or logs,
stored raw audio, and unencrypted secrets.

Run these regression tests: no modal is visible on first load; each modal opens and closes correctly;
computer navigation is visible before scrolling through content; deleting all entries remains empty
after refresh and reopen; examples seed only once. If a local server is running, report how to stop and
restart it and confirm that the URL is temporary. If the first device is a phone, reject `127.0.0.1`,
`localhost`, and `file://` as phone links and verify the same-Wi-Fi address on the physical phone.

Fix every failure you can reproduce and rerun that test. Report PASS, FAIL, or NOT VERIFIED for each
item with evidence. Never label something PASS if you did not actually test it. Do not deploy or add a
new feature.

You still need to import the calendar file and test microphone permission on your physical device. Those checks cannot be proven by an AI builder that does not control that device.

Version 1B: make the one-device app stable

Use Prompt 1B only after every Version 1A test passes.

This step gives the app a stable HTTPS address and makes it installable when the chosen phone or browser supports installation. The diary entries still stay on that one device.

Prompt 1B: Prepare it for daily use on one device

Version 1A has passed its test checklist. Prepare this same app for stable daily use on one device.

Keep the scope small:

- Keep all diary entries in IndexedDB on this one device.
- Do not add an account, cloud database, cross-device sync, analytics, advertising, or a push service.
- Add a web app manifest and service worker so the app can be installed and its interface can reopen
  offline where the browser supports that behavior.
- Serve the app through HTTPS. Microphone, service-worker, and notification-related browser features
  may be restricted on ordinary HTTP pages.

Before deploying or publishing anything, show me:

1. The proposed hosting provider or existing preview service.
2. Whether the final URL will be public, private, unlisted, or access-controlled.
3. Whether the provider adds analytics, request logs, cookies, or injected scripts.
4. Any cost, usage limit, or expiration date.
5. Confirmation that diary entries remain only in this device's IndexedDB and are never included in a
   URL, server request, log, analytics event, or hosted database.
6. Whether deployment is automatic. Require my approval before any future code change is deployed.

Wait for my approval after showing those 6 items.

After I approve:

- Deploy only the static app files to the approved HTTPS location.
- Keep typing available at all times.
- Keep the speech-processing privacy notice before microphone use.
- Request persistent browser storage when supported and display whether the request was granted.
- Keep JSON and plain-text export plus confirmed deletion.
- Keep the recurring .ics calendar reminder as the daily reminder method.
- Show plain instructions for adding the app to the chosen device's home screen. Do not assume the menu
  names are identical across browsers.
- Load the app successfully online once, then test saving, refresh, full browser close and reopen,
  installed-app reopen where supported, offline interface loading, export, deletion cancel, calendar
  import, denied microphone, and the phone layout.
- Give me the stable HTTPS URL as a tappable link and a QR code when the tool supports one. Do not call
  the app phone-ready until I confirm that exact HTTPS link opens on my physical phone.
- After I confirm it opens, test typing on the phone and test microphone permission when the chosen
  phone browser supports speech recognition.
- State anything you could not verify on the physical device.

Version 1 ends here

Your first version is finished when all of these are true:

The stable HTTPS URL opens on your chosen physical device and is not a 127.0.0.1, localhost, or file:// address.
You know who can open that URL.
Diary entries stay on that device and survive refresh and reopening.
Typing works without microphone permission.
Speech input shows the privacy notice and has a typing fallback.
The weekly view uses only your saved entries.
The calendar file imports with the correct local time, daily repeat, and alert.
JSON and plain-text exports open correctly.
Delete requires confirmation.
The phone layout has no horizontal scrolling.

Stop here. Use Version 1 for a week before considering an account, syncing, stored audio, or push notifications.

Privacy facts to understand before real entries

Local means one browser on one device. Opening the same URL on another phone or computer creates a separate diary.
Local does not mean encrypted by the app. Device security, browser-profile access, downloaded exports, backups, and screen access still matter.
Browser storage can be removed. Export entries regularly if they matter to you.
Private or incognito mode is a bad place for this diary. Browsers commonly clear that session’s stored data when private browsing closes.
Speech may leave the device. Web speech recognition can use a browser vendor’s server-based service. Typing is the safer default when that processing is unclear.
A public app URL does not automatically expose local entries. The app must still be checked for analytics, logs, outside requests, URL parameters, and third-party scripts.
The code at that URL matters. Any new JavaScript served from the same website origin could read that origin’s saved entries. Control the hosting account and review updates before deployment.
Exported files need care. JSON and text exports are readable files. Move or delete them according to your own device-security practices.

Avoid putting medical records, legal secrets, financial account information, passwords, workplace confidential information, or anything belonging to another person into a first AI-built diary app.

Version 2: plan syncing and real push reminders (optional)

Version 2 is a separate product decision. This prompt creates a plan first. It must not start building until you review and approve the plan.

Plan a private synced version of the verbal-diary app. Do not write code, create accounts, connect a
database, add a notification provider, or deploy anything yet.

Prepare a plain-language plan covering:

1. Authentication and account recovery.
2. Per-user authorization so one user can never read another user's entries.
3. Database provider, storage location, encryption in transit, encryption at rest, backups, retention,
   and permanent deletion.
4. Every place diary text, metadata, logs, errors, and backups could be stored.
5. A push or email reminder provider that can operate while the browser is closed, including device and
   browser limitations.
6. The exact free limits, paid costs, and usage assumptions.
7. Secret and API-key storage on the server.
8. Rate limits, abuse protection, dependency review, and security updates.
9. Export, account deletion, and backup-deletion behavior.
10. A test plan for account isolation, lost passwords, revoked sessions, failed sync, offline edits,
    notification denial, export, deletion, and backup recovery.

Separate facts you verified from assumptions and unresolved questions. Link to each provider's current
official privacy, security, pricing, and data-retention documentation.

End with a go/no-go checklist and wait for my approval. Explain that an AI-generated plan or codebase
does not certify the app as secure and recommend an independent security review before storing other
people's private diary entries.