An honest split between owner input time and work output time is not recoverable. The project records commits, not chat timestamps and not time spent by either side. Any figure claiming that division would be invented, so none is offered here.
Across the period the logged commit-window span is 437 hours 28 minutes — the sum of each active day's first-to-last commit timestamp. That is an activity window, not labour. It contains breaks, it says nothing about intensity, and it cannot be divided between the owner's direction and Buddy's execution. It is included because it is measurable, and bounded here because it is easy to misread.
The 1,080 commits are not 1,080 distinct tasks. The same completed work is frequently implemented in the site repository and then documented in the knowledge base, so the two counts overlap by design. Commit counts and file counts are evidence of scope, never a measure of time spent.
The 500–700 hour figure is therefore a human reproduction estimate — what a competent specialist would need to recreate this outcome to the same standard — not a record of hours worked. The owner's own time supplying commercial judgement, source copy, approvals and supplier decisions is real and substantial, but it was never logged, so it is left unclaimed rather than guessed.
This case study makes no claim about ranking, traffic or sales movement in the two-month window. Those outcomes need time and their own measured review; the work should be credited for the changes delivered, not for results that have not yet had time to appear.
To produce a true input/output split on future engagements, owner inputs and work start/complete events would need to be timestamped per task. That instrumentation does not exist retrospectively and has not been simulated.
