Energy tracking for better daily decisions

Daygrain is my current product experiment: a personal energy and decision-making app built around daily logging, Apple Health signals, and honest self-awareness. Building in public — not a client pitch, but proof of the same builder mindset I bring to founder engagements.

  • Health
  • iOS product

Context

I build my own products alongside client work. Daygrain started from a simple observation: mood and energy swings were hard to explain in hindsight, and generic wellness apps either over-scored everything or buried the signal in charts. The goal was a calm daily log that connects how you feel with sleep, activity, and patterns over weeks — without turning life into a gamified streak.

Challenge

Solo product work forces trade-offs every week. The interface had to feel trustworthy on a dark, minimal canvas while staying fast to log — one tap for mood, optional notes, and a year-at-a-glance view that actually helps reflection. Apple Health integration needed to add context without making the app feel like a dashboard clone.

My role

I own product direction, UX, visual design, and the public build narrative. Decisions are made the same way I advise founders: ship the smallest honest version, learn from real usage, document what failed, and resist feature sprawl until the core loop is solid.

What I built

  • Daily energy and mood logging with a year overview — patterns visible without opening analytics rabbit holes.
  • Apple Health hooks for sleep and activity context, surfaced only when they clarify the day — not as default noise.
  • Dark, forest-green visual system aligned with the brand on site — PixelBlast background is the same language as the product band on petermarc.com.
  • Building in public on X: real product calls, scope cuts, and TestFlight → App Store milestones documented as they happen.

Where it stands

Live on the App Store, iterated in public. Daygrain is not positioned as a case study for hire — it is evidence that I sit on the founders' side of the table: shipping under constraint, making product calls without a large team, and staying honest when something does not land.

Have a product flow that feels harder to explain than it should?

Send me your product, MVP, deck, or prototype. I'll tell you where I'd start.