The project window is September 18–October 1, 2026, inclusive. The 23 commits span six commit dates and include implementation, refinements and housekeeping. Fifteen successful deployment workflows are not fifteen verified human approvals. Three explicit approvals were recovered from the available conversations; that is not proof that every change received a separately recorded review.
*The 87.45% figure compares 7,370,872 original image bytes with 925,168 bytes for one largest WebP variant per original across 12 images. It is not a page-speed, ranking or total page-weight improvement. The 28 consolidated city-parent URLs use one-hop redirects; the parent records were not deleted.
The owner reports spending about two hours personally on this project; this is a retrospective firsthand estimate, not a recovered timesheet. The 91–160-hour manual estimate is the sum of 15 non-overlapping specialist workstreams grouped into nine cards above. It assumes an experienced WordPress/PHP/frontend specialist with the existing theme, HighLevel access, supplied reference guide, owner facts/assets and reusable libraries. It excludes from-scratch CRM or native apps, new brand discovery and unperformed comprehensive SEO/AI testing. Subtracting about two hours yields an illustrative 89–158-hour difference between unlike measures, not a verified total labor saving: other human labor and agent active-compute hours were not recorded.
The examples show distinct request-to-readiness and approval-to-deployment intervals. They are elapsed clock time, not labor, and should not be added together. Neither the 14 calendar days nor the 10m 36s combined duration of production workflows is a timesheet. The documented client site and staff-tool releases went to production. GA4 web-stream access and post-release business outcomes remain open. The client is unnamed and no private staff visuals or customer records are shown.
