Work Logs for Solo SaaS Builders: Multiple Projects, One Focus Report

If you ship more than one product, your week is a blur of context switches: one app in the morning, a second product after lunch, a bug in a third thing at 11pm because you couldn't sleep until you fixed it. Clients, investors, co-founders, or just your own future self will eventually ask where the hours actually went — and "I worked on stuff" doesn't hold up as an answer for very long. This is a guide for solo builders who need one report that still respects the boundaries between products, instead of blurring everything into a single undifferentiated number.

The multi-project problem, named directly

It's one person and several products, and the usual tools weren't built for that shape of week. Traditional timers force manual tagging — stop, pick a project from a dropdown, start again — which is exactly the kind of friction that gets skipped the moment you're in flow, meaning the log ends up wrong precisely on the days it mattered most. Screenshot tools are worse here, not better: they have no concept of "project" at all, just apps and windows, so a code editor open across three different repos looks identical no matter which product it's actually touching.

Using focus criteria as project scopes

The fix is to treat the goal statement itself as the project boundary. A day's focus criteria can be product-specific — "ship the report polish updates for Product A" — or explicitly split across a portfolio day — "split time between Product A feature work and Product B customer support." Either way, the goal you write down is doing double duty: it's both the thing your time gets scored against, and the label that keeps the report legible when you look back at it later.

What the report looks like across products

Because classification runs against on-screen context — active app, window title, OCR text — the resulting time-allocation rows naturally group around the signals tied to each product: a specific repo name in a window title, a specific project's admin dashboard, a specific set of support tickets. When the goal for the day names more than one product, the reason column reflects that directly, naming which project a given block of time belongs to rather than leaving it implicit. You end up with one table that still reads as multiple projects, instead of a single blended number that hides which product actually got the hours.

A realistic build-in-public week

Picture a normal week for a two-product solo builder: Monday and Tuesday are heads-down feature work on Product A, chasing a specific release. Wednesday splits between a support backlog for Product B and a marketing post that mentions both products. Thursday is almost entirely Product A bug triage after a rough deploy. Friday is scattered — a bit of everything, including two hours that turn out to be pure admin, unrelated to either product's stated goal, and correctly logged that way instead of being padded into something it wasn't. That's what an honest build-in-public week actually looks like in a report: uneven, occasionally blended, and legible instead of smoothed over.

Sharing selectively

Not every report is for the same audience. A project-scoped report — a day or week where the goal named one specific product — is exactly the kind of thing worth sending to a client or a co-founder tied to that product. A broader personal weekly review, blending both products plus the admin overhead in between, is more useful kept private, as a builder's own read on where the month actually went. The report format supports both; nothing about generating one commits you to publishing it anywhere.

The limit of one goal at a time

Worth being honest about a real limitation: if you bounce between three products inside a single hour, classification quality depends heavily on how clearly that hour's goal was stated going in. A goal that tries to cover too much at once produces vaguer reasoning, the same way an unclear instruction produces a vaguer result from anyone you delegate to. The practical pattern that works well: one primary goal per day, or per half-day if a day is genuinely split, rather than trying to write one goal statement that tries to hold three products at once.

Why this beats a Notion work log

The alternative most solo builders actually use is an end-of-day journal entry — a Notion doc, a personal changelog, a running note. It works right up until the day you're too tired to write it, which for most people is more days than not. Automatic capture plus reasoned classification doesn't have that failure mode: the report exists whether or not you had the energy to narrate your day, because it was built from what was already captured while you worked, not from what you remembered to write down afterward.

The actual need

Solo builders don't need surveillance of their own workday. They need a memory that can explain itself — especially once "I built three products this month" needs receipts, whether that's for an investor update, a client, or just your own sanity when you're trying to remember what actually happened in March. A focus report is that memory, packaged so someone else can read it without ever having to watch your screen.

Generate one from your own week

Try it against your own multi-project week — download FocusLens for Mac, set a project-scoped goal for your next work session, and see how the report handles the split. For a look at what a finished report reads like end to end, see the sample focus report walkthrough or the report section on the homepage.