Faizan OS Week 3: A Milestone Feed and the First Privacy Bugs

Week two ended with a pattern settling in: build something, use it for real, then find out what it's actually costing you. Week three kept that pattern going, but it also handed the app its first module count explosion and its first bugs that weren't about speed, they were about something showing up on screen that shouldn't have.

Table of Contents

• Five Modules in Two Days
• Life Timeline: The Curated Milestone Feed
• When Privacy Mode Didn't Mean Privacy
• The Bug That Could Have Quietly Erased a Save
• What's Next

Five Modules in Two Days

One stretch this week added Career, Decisions Log, and a ported-over Study Abroad tracker, on top of a new Content Calendar module, almost back to back. Career started as a straightforward job-search tracker, then got renamed, then had a Next Action field pulled out, then had its edit modal replaced with a plain read-only page. Decisions Log went through the same kind of churn, added, then had its card preview trimmed down within the same day.

None of this was indecision for its own sake. It's what actually happens when you can describe what you want but can't picture the whole thing at once. You ship a first version, look at it for five minutes, and immediately know what's wrong with it. That loop is fast when the person doing the describing is also the only user.

Life Timeline: The Curated Milestone Feed

The bigger addition was Life Timeline, a module that pulls milestone-worthy events out of other modules instead of asking me to log them separately. A big trip ending, a savings goal hit, an investment milestone crossed, all of it lands in one feed instead of living wherever it happened to originate.

Getting there wasn't clean. The first version showed recurring bills as if they were milestones and let events bunch up around the same date until the feed looked cluttered instead of curated. Future events showed up mixed in with past ones with no way to tell them apart. Each of those got fixed one at a time: recurring bills dropped out entirely, future events got shown but visibly greyed out, and a "notable transaction" flag was added so a big purchase only shows up if it's actually worth remembering, not just because it crossed some dollar threshold.

The idea behind Life Timeline is one I keep coming back to with this app: the value isn't in any single module holding more data, it's in the connections between modules actually surfacing something you'd otherwise have to go looking for.

When Privacy Mode Didn't Mean Privacy

Faizan OS has a privacy toggle that blurs dollar amounts across the app, useful for screen-sharing or just not wanting numbers visible if someone glances at your screen. This week, that toggle turned out to have holes in it.

On the Investments page, a redesign had quietly missed applying the toggle to entire sections: the hero total, portfolio rows, monthly contributions, one-time injections, snapshots, even milestone progress bars were all showing real numbers regardless of whether privacy mode was on. Return percentages had the same gap. Then, separately, a milestone calculation was found to be leaking real estate values through in a snapshot total even when that asset was supposed to be excluded from the portfolio view entirely.

None of these were dramatic in the way a crash is dramatic. Nothing broke. The page loaded fine, everything looked normal, right up until you turned privacy mode on and realized it hadn't actually hidden anything on that particular screen. That's what makes this kind of bug worth naming separately from a performance bug: a slow page just wastes your time, but a privacy toggle that silently doesn't apply somewhere is the kind of thing you only find by actually testing the thing it's supposed to do, not by watching for something to visibly go wrong.

The Bug That Could Have Quietly Erased a Save

The scariest fix this week wasn't about anything showing up on screen. It was about what happens when a load fails.

Several modules save by reading the full saved state, then writing back an updated version. If the initial read failed, silently, the code was treating that failure as "there's nothing here yet" instead of "I don't actually know what's here." Which meant a failed load, followed by a normal save, could have quietly replaced real saved data with an empty or partial version, no warning, no error, nothing to notice until you went looking for something that was supposed to be there and wasn't.

Nobody hit it. It got caught while working through modules asking a boring but necessary question: what does this do if the read right before it fails? The fix makes every module refuse to save on top of a failed read instead of assuming the failure meant "empty."

This is the same shape of bug that shows up more than once building something like this: it's never about what happens when everything works, it's about what happens on the one path where something doesn't, and whether the code assumes the best case or actually checks.

What's Next

By the end of week three, the module count had jumped noticeably, and the app had its first real lesson in what "privacy" actually requires: not just a toggle that exists, but one that's been checked against every screen that shows a number. Week four keeps building on that same idea, this time with a redesign that touches nearly every module at once, and the kind of visual bugs that only show up once you're actually living inside the new look every day.