Faizan OS Week 2: Food Diary and the Duplicate Reads Nobody Noticed

Week one of Faizan OS was about getting a baseline in place: thirteen ported modules, a website, the start of Quick Capture. Week two was quieter on the surface and messier underneath, the kind of week where you add one new thing and discover three old things were already broken.

Table of Contents

• Finishing What Week One Started
• A Second Website, Forked
• Food Diary Arrives
• The Duplicate Reads Nobody Noticed
• What's Next

Finishing What Week One Started

The first few days of week two were cleanup, not features. Topic Ideas import got fixed, mobile layout issues got ironed out, and search autocomplete kept getting refined. None of it was glamorous, but it's the kind of work that decides whether the app feels solid day to day or just looks solid in a demo.

This stretch is easy to skip over when telling the story later, but it's honestly most of what building something actually looks like. Ship something, then spend a few days making it not annoying to use.

A Second Website, Forked

Faizan's Website module, the one for publishing to faizanazhar.com, had only existed for about a week. It got forked into a second module for odessys.com, following the same pattern: post editor, Cloudinary image uploads, AI-prompt-assisted drafting where I write a prompt, paste it into a separate Claude conversation, and bring the result back in.

The fork added one new piece the original didn't have: a Portfolio and case-study tab, since an agency site needed a way to show finished work that a personal blog didn't.

Forking a module instead of building a second one from scratch turned out to matter later. When a bug showed up in one Website module, it usually showed up in the other too, for the exact same reason, which made both easier to fix once found.

Food Diary Arrives

A new module landed this week: Food Diary, for logging meals. It shipped and then got iterated on almost immediately, gaining pagination and calendar-based day and range navigation within the same stretch.

Food Diary didn't last in this form. It would later get replaced entirely by a broader Routine module that logs a full day across custom categories, not just meals. But it's worth naming here because it's a good example of how modules in this app actually evolve: ship something narrow, use it for real, then either extend it or replace it once the narrow version's limits become obvious.

The Duplicate Reads Nobody Noticed

The most important work this week wasn't a new feature at all. It was a batch of fixes to a bug that had been quietly running since the very first modules landed in week one: several modules were re-fetching the same Firestore data over and over instead of reading it once and reusing it.

Watch Queue, Trips, and Liabilities all had uncached duplicate reads. Net Worth and Patterns were independently duplicating reads that other modules had already made. Both Website modules were re-fetching their entire post collection on every load instead of just the new data.

None of this was visible as a bug in the normal sense. Nothing crashed, nothing looked wrong on screen. It just meant the app was doing more work than it needed to, quietly, in the background, since the day those modules were first built. Finding and fixing it took going module by module and asking a boring but necessary question: does this actually need to fetch this again, or do we already have it?

What's Next

By the end of week two, the module count had grown by one, but the more meaningful change was under the hood. A pattern was setting in: build something, use it for real, and only then find out what it's actually costing you. Week three is where that pattern keeps going, with a curated milestone feed and the first bugs that touch something more sensitive than performance: privacy.