A Practical Quantified-Self System for Indie Developers

Start with a decision, not a data warehouse

Write down a recurring decision you want to improve. Should you protect an earlier focus block after later nights? Does a launch cadence leave enough recovery for support work? Does a morning planning habit coincide with finishing the day's most important task? Each question suggests a small set of signals.

Avoid importing a metric merely because an API exposes it. More variables create more chances for a coincidental relationship and more maintenance when schemas, devices, or integrations change. A system that helps one weekly decision is more valuable than a personal data lake you stop reviewing.

Build the smallest useful signal stack

Use four layers: personal context, subjective state, observable work, and optional business outcomes. Apple Health can centralize permitted health and activity information from Apple devices and compatible sources. GitHub can provide dated contribution activity under its documented rules. Mood and focus still need a brief self-report because neither platform knows how the work felt.364

Keep value types explicit. A step count and a 1 to 10 mood rating are not equally measured. A contribution event and monthly recurring revenue do not share the same cadence. A readiness score is not raw physiology. A useful system retains those distinctions instead of normalizing everything into one life score.

Make dates, definitions, and privacy part of the system

Define where overnight sleep belongs, which time zone governs a workday, how late coding crosses midnight, and what done means for the outcome. Version those definitions when they change. Leave missing data missing and mark device or integration changes so the timeline does not imply continuity that is not there.

Connect only sources you are comfortable bringing together. Apple documents permission protections around Health data. Swaymark says users choose sources and can revoke integrations, with read-only Apple Health access for requested categories. Its public privacy language does not claim that all data remains only on-device, so review the current policy before deciding what to connect.52

Run a weekly review that respects exceptions

Once a week, pick one comparison. Name the window and sample, inspect typical values, and read the days that contradict the apparent pattern. Add notes about launches, illness, travel, caregiving, marketing pushes, outages, or unusually difficult technical work.

Describe observations carefully: moved together, tended to follow, or worth testing. Do not say sleep caused revenue, mood caused commits, or a workout produced activation. Product outcomes have many influences and often lag the work that contributed to them.

• Review one question per week.
• Show the sample and missing days beside the result.
• Separate activity from quality and customer value.
• Write down the strongest counterexample.
• Save only observations that remain useful and evidence-qualified.

Turn the observation into one small experiment

Choose a reversible change with a start date, end date, and stable outcome. Examples include protecting the first hour from messages, ending late coding on three nights, or reducing the top-task scope after a poor sleep window. Change one main variable where practical.

At review, keep, revise, or stop the experiment. No effect is a result. So is a pattern with too few observations to trust. Treat health and recovery data as context, not diagnosis. Persistent fatigue, sleep problems, mood changes, or concerning physiological values belong with qualified medical care, not another dashboard.