One person identified a problem in a Reddit thread. No code was written by hand. Claude Code handled every artefact — research, mockups, visualisations, proposal, export. The human provided direction, taste, and judgement. The machine provided execution.
| # | Step | What happened | Output |
|---|---|---|---|
| 1 | Reddit screenshot | OP (groovyipo) described a manual monthly process: pulling Bill.com AP data, cross-referencing QBO AR invoices, applying packaging formulas in Excel to verify customer billing against supplier costs. Estimated 20–30 hrs/month lost. | Starting point — problem identified from a single screenshot with zero prior context |
| 2 | Framing the problem | Mapped the OP's context onto a familiar domain (bakery). Explored three demo options using real integrations before user redirected to use Bill.com and QBO directly with a bakery as the fictional client context. | Three options surfaced and evaluated. Bakery context confirmed. Scope locked. |
| 3 | Identifying the pith | Stripped back the OP's request to its core: two systems that speak different languages — supplier line items vs bundled customer products — with a human doing the translation in Excel every month. The gap is structural, not incidental. | Core problem statement: "the translation gap between two systems that speak different languages" |
| 4 | Senior dev challenge | Introduced an adversarial senior developer's perspective. She would push back on building a dashboard and redirect to the real hard problem: the assembly engine (Bill of Materials). The formula layer is the fulcrum — without it, you just have two lists of numbers that cannot be compared. | Architecture reframe: BOM engine is the core problem, not the UI. Dashboard idea discarded. |
| 5 | Formula config mockup | Built an interactive HTML mockup of the only UI worth building: a config screen where users define packaging formulas (supplier SKU → customer product, with quantities and units of measure). Included expandable rows, a "needs review" warning state, and an inline add form with realistic bakery data. | billing-recon-formula-config.html — interactive mockup, live in browser |
| 6 | Data flow visualisation | Built a three-column HTML visualisation showing a real Bill.com AP invoice on the left, the formula engine in the middle, and a QBO AR invoice on the right. Included a full reconciliation result table at the bottom and a simulated alert email showing exactly what the system sends when a discrepancy is found. | billing-recon-visualisation.html — end-to-end data flow made visible |
| 7 | Quick win strategy | Identified that the fastest path to saving 10 hrs/month is automating data extraction only — no BOM, no UI. The OP explicitly said Bill.com has no CSV export for line-item detail. Pulling both data sources via API into a clean spreadsheet every morning removes the hardest manual step immediately. | Phase 1 defined: one script, one week, 10 hrs/month saved before the full build begins |
| 8 | Chain of scripts | Confirmed the entire end-to-end solution is four scripts in a chain. No app, no server, no UI required. The formula config becomes a JSON file. Value is delivered incrementally — each script added saves more time. The pipeline is independently testable at every stage. | Pipeline architecture confirmed: fetch → transform → reconcile → alert |
| 9 | Option A — one-pager | Built a client-facing proposal in HTML: before/after workflow comparison, three-phase delivery plan with time savings at each step, ROI numbers, and a fixed-fee Phase 1 call to action. Designed to be printed and handed to a decision-maker. | proposal-a-onepager.html — signs contracts |
| 10 | Option B — pipeline diagram | Built a technical proposal in HTML showing the four-script chain with data sources, config feeds (bom.json, tolerance.json), outputs at each stage, and value unlocked per phase. Designed for the technical conversation that happens after the contract is signed. | proposal-b-pipeline.html — grounds the build conversation |
| 11 | Merged into one scroll | Merged A and B into a single-page narrative with a combined header, the four-script pipeline diagram embedded mid-page, and a clear three-phase delivery plan below. One scroll tells the full story: problem, solution, proof, ask. No tabs, no friction. | proposal-merged.html — the final client artefact |
| 12 | Anonymised | Removed the bakery name from the document to keep the client context neutral and reusable across prospects. Replaced with the OP's Reddit username to maintain the origin story of where the problem was first identified. | Copy finalised — no proprietary names, ready to share |
| 13 | PDF export | Converted the final HTML proposal to PDF using headless Microsoft Edge via command line. No print dialog, no manual steps. | proposal-merged.pdf — ready to send |
| 14 | This document | The session itself became an artefact — a case study in what a non-technical operator and Claude Code can produce together in under an hour, starting from a screenshot of a stranger's Reddit post. | session-summary.pdf — the meta-artefact |