Project E — Personal Study Tracker

Part 1 · The case

Danish is studying for a professional exam while working full-time. Between a 9-to-5 and family life, his study happens in messy bursts: 30 minutes on the train, an hour after the kids sleep, a Saturday morning at a café. He wants to know, honestly, how much he studied this week — not what he felt like he studied.

He tried a notebook (loses it), a spreadsheet (won't open on his phone at 11pm), and a public habit-tracker app (uncomfortable sharing exam anxiety with strangers). What he wants is small and specific: a tracker that is only his, on any device he signs into, that shows the week at a glance.

What he wants: log a session in five seconds — subject, minutes, mood, one-line note — and see a weekly grid where the darker squares are the bigger study days. That's what this project builds.

Part 2 · What you're building

A Personal Study Tracker. One private user, one private log, one honest weekly view.

Danish signs in on his phone or laptop, taps "Log a session", fills a short form, and sees his week update. Nobody else — not even other signed-in users of the same app — can ever see his rows. The opposite audience from Lesson 4 (many people, one shared number). Same toolkit, very different security posture.

A few terms up front:

• Private — only the person who signed in can read or change these rows. The database itself refuses everyone else, not just the app being polite. Even if someone poked at the app's back door with a technical tool, the database would still say "no".
• Session — one sitting of study, from "started" to "stopped". One row in the database per session.
• Heatmap — a small grid, one square per day, where darker squares mean more minutes studied that day. Danish's week at a glance.
• Owner stamp — every row is tagged with the account id of the person who saved it. The database checks that tag on every read, so only the owner can see it.

Part 3 · Who uses it & how

Part 4 · The Power Prompt to start

A few plain-language notes before the prompt:

• Sign-in — this app starts at the sign-in screen. Nothing is visible without an account. Very different from Project A (no sign-in) or Project C (a short shared code).
• Owner-only rule — every row is tagged with the signed-in account id, and the database's own rule reads "you can only see rows where owner = you". This rule lives inside the database, not inside the app, so it can't be bypassed by cleverness.
• Optional forgot-password flow — because there is no admin who can rescue Danish's data, we set up the "forgot password" email link on day one. If he loses the password, the email link is the only way back in.
• No sharing (on purpose) — no share link, no export-to-public. If you want a private log, adding a share button is where private logs stop being private.

Goal — Build a private study tracker for one person. Log sessions on the phone, see a weekly heatmap, and keep everything visible only to the signed-in owner.

Roles — One role: the owner. Anyone can sign up for their own account, but every account only ever sees its own data. No admin, no coordinator, no public reader.

Layout — One page after sign-in. At the top, a short form: subject (short list of options the owner can edit), minutes (number), mood (three faces), one-line note. Below the form, a 7-day heatmap of the current week. Below that, the last 20 sessions with an edit and delete button on each.

Features — Email/password sign-in with a "forgot password" email link, plus Google sign-in as an option. Every session row is tagged with the signed-in account and the date and time it was saved. The database's own rule allows a person to read, change, or delete only their own rows. Editing a session changes only that row; deleting removes only that row. The heatmap and the recent list read from the same rows — no separate reporting step.

Output — A private dashboard the owner can open on any device where they sign in. A "download my data" button that gives the owner a spreadsheet of their own sessions.

Part 5 · Data & flow

One small table

This project is genuinely tiny — one list of rows is enough. A "table" is just a named list of rows in the database, and each row is one saved thing.

• sessions — one row per study sitting. Columns: id, owner id (the account that saved it), subject (e.g. "Torts"), minutes (a number), mood (happy / neutral / tired), a one-line note, and the exact date and time it was saved.

Everything the app shows — the weekly heatmap, the recent list, the total minutes — is computed from this one table. No copy, no summary table, no separate report.

The security rules

This is the whole product, so it's worth stating carefully. The rules live inside the database itself — not in the app code.

• Reading — a signed-in person can only read rows where owner id equals their own account id. Anyone else asking for the same rows is refused, even if they know the row's id.
• Writing — a signed-in person can save a new row only if the owner id on that row is their own account id. The database rejects any attempt to save a row stamped with someone else's id.
• Changing / deleting — same rule. You can only change or delete rows that are already tagged as yours.
• Not signed in — the database returns nothing and accepts nothing. The sign-in page is the front door and there is no side door.

Part 6 · What matters for this project

From the five foundations in Lesson 1, this project leans on:

1. 1Auth (the star)

   The whole product is 'sign in, then see your stuff'. Email/password with a 'forgot password' email link is the baseline; Google sign-in is a nice option because it removes one password to remember. There is no anonymous mode — the app has nothing to show until it knows who you are.

2. 2Security

   The strictest posture in this whole course. One rule, applied to every read and write: 'owner id must equal my account id'. Simple to state, and because it's enforced by the database itself, hard to accidentally break.

3. 3Database

   One tiny table. The interesting part isn't the shape — it's the security rules attached to it. Same three commands as Lesson 2 (save a row, read your rows, delete a row), but every one of them is filtered by the owner rule.

4. 4Cloud (the always-on computer)

   Small role. It hosts the app so Danish can open it on his phone at 11pm. Optionally, a tiny scheduled job can send him a weekly email summary — a quiet nudge without a public share link.

5. 5Real-time

   Not needed. There is only one user of each account. If Danish is logged in on two devices at once, a quick refresh is fine — we don't need instant pushed updates the way Project C did.

6. 6AI

   Optional and last. A 'reflect on my week' button that reads only Danish's own rows and writes a paragraph — 'you studied 6 hours this week, mostly Torts, mostly on weekends' — is a nice touch, but the app is useful without it.

Part 7 · Public vs private, same toolkit

It's worth pausing here. Project C (Lesson 4) and Project E (this one) look like different products built on different technology. They're not. They're the same toolkit dialed to opposite settings.

Same database, same auth, same rules engine. The rule you write is what makes the product public or private. This is the single most important idea in the whole course: the security rule is the product.

Part 8 · Strengths ✅

• Genuinely private. The rule is enforced by the database itself, so even a curious technical user can't peek at another account's rows.
• Fast to log. A session is four fields and a save button — five seconds on a phone, which is the whole point of tracking honestly.
• Works across devices. Sign in on the laptop at home, on the phone on the train — same data, no export/import dance.
• One source of truth. The heatmap, the recent list, and the weekly total all read from the same rows. No copies, no drift.
• Cheap forever. One person's study log for a year fits comfortably in the free tier of any modern database.

Part 9 · Weaknesses & trade-offs ⚠️

• Forget your password with no email set up and the data is gone. There is no admin to rescue you — that's the point. Set up the 'forgot password' email flow on day one, and use a real email address you'll keep.
• No accountability partner. Because nothing is shared, nobody can nudge you when you skip a week. Some people study better with a witness; this design isn't for them without the 'trusted viewer' extension below.
• Two devices, edited offline, might briefly disagree. If you log a session on the plane on your laptop and another on your phone, whichever syncs last wins for that exact row. Fine in practice; worth knowing.
• The heatmap is honest, not motivating. A slow week looks like a slow week. If you need encouragement, add a small streak or 'best day' badge — but don't turn the app into a game if you want the data to stay truthful.
• You are the whole user base. If the app breaks on your phone at 11pm, there's no support ticket to file. Publish it, then keep the code somewhere you can open it.

Part 10 · Dummy file to test with

Because this app is private by design, there's no "shared sample data" to hand out — every account starts empty on purpose. But for a demo (or to see the heatmap fill in without waiting a week), here's a made-up eleven-session backfill you can import under your own account.

Part 11 · Extend it

• Add a monthly review page that reads the same rows and shows totals by subject.
• Add an AI 'reflect on my week' button that reads only your own rows and writes a one-paragraph summary — a diary, not a report card.
• Add a 'download my data' button that gives you a spreadsheet of your sessions. Owning your data is part of the promise.
• Add a scheduled weekly email that shows your own numbers. Same privacy rule — the email goes only to the owner.
• Advanced: a 'trusted viewer' invite that lets one specific other account read (but never edit) your rows. Powerful, and a real security decision — the moment you add it, 'only you' becomes 'you and one other'. Do it deliberately, if at all.