Project case study
VizGrind
I wanted one place for my plans, workouts, food, money, and reflection. VizGrind is the personal operating system I’m building around that.
My role: Product direction and iteration with AI-assisted development.
Watch the interactive walkthroughGitHub has the June 2026 version. The walkthrough shows later work from my private app. The October checks are described below.
How it works
My day, in one place.
The homepage brings my plan into a list I can check off as I go.
How it works: AI organizes the plan from my journal into actions supported by my own words. The original writing stays separate, and completed tasks save to my account.
A workout that fits the time I have.
I choose the time I have, then review what changes in today’s workout.
How it works: a rules-based time model counts sets, rest, equipment changes, warm-up, and cardio. It trims the session while protecting primary lifts. It starts from the planned workout, not a new AI guess.
Describe the meal. Check the details.
I describe what I ate, then check the meal details before saving.
How it works: AI can estimate calories and macros from text or a food photo, while preserving nutrition numbers I supply. This clip shows text entry. Photo estimates still need review.
See where the money is going.
I allocate money into budget envelopes and track spending against them.
How it works: each envelope has an allocation and remaining balance. Transactions belong to an envelope, so I can see what is left for each part of my budget.
A place to close out the day.
The journal gives me room to reflect and write out what comes next.
How it works: drafts are kept locally, and account saves check the entry’s revision. The journal closes after a confirmed save.
Write it down without losing the original.
My writing stays mine, even when the app makes it easier to act on.
How it works: the formatted daily plan is cached separately from the journal. A source hash identifies which version of my writing it belongs to.
That is what I mean by a personal operating system.
Planning, training, food, money, and reflection belong in the same picture.
I am both the builder and the customer. I use the app, notice what gets in the way, and bring that feedback straight into the next iteration.
I get to be the builder and the customer.
I use VizGrind in my own life, so the feedback is immediate. If something gets in the way, I can be specific about what needs to change and bring that straight into the next version.
One example: my daily plan was a block of journal text. I wanted readable actions I could check off. The October release added that, with saved progress, while keeping my original writing intact.
- My part
- Product direction, interface feedback, and ongoing iteration with AI-assisted development.
- Documented development
- June to October 2026
Ongoing personal project. - Built with
- Next.js · React · TypeScript
Supabase · OpenAI · Vercel
What you can do with it
The app started with workout and nutrition flows. The current build also includes budgeting, daily planning, and a journal. The important part is being able to move between those things without starting over every time.
- Log sets, review progression, and adjust a session to the time available.
- Turn a meal description into a reviewable entry before it is saved.
- Keep a budget, reflect in a journal, and follow a saved daily plan.
Technical overview
React and TypeScript handle the interface inside a Next.js app. Server routes handle persistence and AI requests. Supabase provides authentication and a Postgres database with policies that scope records to their owner.
AI helps interpret and organize information. Logging and progression also have deterministic paths, so the basic app can keep working when an AI request fails.
Keeping a workout when the connection drops
Workout completion has a device outbox with retry state. Drafts preserve the session in progress, and completion is designed to handle retries without creating duplicate records.
Checking AI output before using it
The plan formatter uses a structured schema. Each action needs a supporting excerpt from the original writing. The organized version is stored separately from the journal, with revision checks to keep an older response from replacing newer work.
Testing the behavior that matters
The current private codebase includes Vitest coverage for progression, local dates, offline recovery, nutrition writes, and plan persistence. Browser audit scripts check important flows and phone layouts. The release process runs lint, tests, and a production build.
A decision, the changes, and the checks
Making the plan useful. I did not want the homepage to just repeat a block of journal text. I asked for the full plan to be organized into readable actions. That led to a separate formatted view, then saved checkboxes with undo. My original writing stays intact.
The problem I pointed out
The homepage was showing my plan as a block of journal text inside a scrollable area. I wanted the full plan visible and organized into actions I could follow.
My decision and the implementation
I asked for a readable, organized plan, then for checkboxes so I could mark things done. AI-assisted development implemented the formatter, separate saved presentation, and persistent task states. The original journal stayed separate from those changes.
What the release checks showed
On October 26, the organized plan survived reload without another formatter call, and the original journal was unchanged. The next release tested checking, undo, reload restoration, and failed saves. A database test also confirmed that changing one task preserved another task’s status and rejected an outdated plan revision.
These are documented release checks, not a claim that I independently wrote or personally ran every test. Phone-width browser checks passed; physical iPhone testing was not verified.
Read the dated verification summaryMaking voice capture recoverable. A recording upload failure exposed a gap in recovery. The later implementation saves audio locally before uploading, splits larger recordings into smaller segments, and provides retry and export options.
Handling unreliable connections. Early development added a completion outbox for workouts. That work carries through the app: a save needs a clear state, and a failed request should leave something the user can recover.
Development history and source
I direct the product through concrete feedback on how it should work. The development chat shows that process clearly: identify the friction, work through a change with AI assistance, then check the actual interface and saved behavior.
The available Git history begins with a baseline in June 2026. Later release records continue through October. That gives a documented development window, but it does not tell me how many hours I personally spent on it.
The walkthrough uses sample data. GitHub contains an early public version, last pushed in June 2026. The current private app includes later work shown here.
See the early source on GitHub