Portfolio running cost calculator — drop-in widget

Date: 2026-05-21 · Status: sketched, NOT built · Build effort: ~2 hr for v1 (single-page rollups, no cross-page yet)

The principle Dan stated

“I would like to have a running cost calculator for certain things, this should work across-the-portfolio, as a standard to embed into pages.”

A drop-in widget that: - Sums costs annotated on the same page - Shows running totals over multiple time windows (lifetime, YTD, this month, last 12 mo) - Works on equipment service logs (Z665 $500, Husqvarna future repairs), contractor invoices (Jorge’s 15-20 scanned receipts), claims (Liberty Mutual money map), perhaps more - Same <script> tag works across pa.gf.cx / dare.co.uk / dogwood / audrey - Same data-attribute markup pattern on cost entries

How it should feel as an author

You author cost data in-line on the page using data-cost attributes:

�STASH2�

The drop-in widget scans the page for these annotations + computes rollups:

�STASH3�

Place the display target anywhere on the page:

�STASH4�

Architecture

�STASH5�

Data attribute spec

�STASH6�

The widget display target accepts:

�STASH7�

Build phases

�STASH8�

Why this compounds

Three forces:

1. Authoring discipline pays back on every page. Once Dan annotates a single invoice with data-cost, that page automatically shows running totals. No re-work; the data is the display source.

2. Cross-page roll-ups unlock once Phase 2 lands. “What did Jorge cost this year?” becomes a directory query — same shape as the contractors directory we just shipped. As more cost entries land, the queries get more powerful.

3. The widget travels. Same <script> works on dare-co-uk client engagements (billable-hours rollup), dogwood (boarding revenue), audrey (Shopify product costs). One widget, four portfolio brands, each context contributing data.

Resume conditions

Build Phase 1 when ANY:

1. Jorge’s 15-20 invoices scan in — that’s enough data points to make a running-cost view immediately useful (15-20 entries shows pattern, not just a single $500).
2. A second engaged contractor accumulates 3+ service log entries — N&J on Z665 after a second service round, Newtown on Miele after the next visit. At that point the “what have we spent” question becomes operational.
3. Claim 046414618 reaches its payment milestones — the money-map block in the cockpit would benefit from automated rollup (received vs spent vs owed).
4. A new audrey/dogwood use-case demands it — billable hours, product COGS, etc.

Sibling memories

• feedback_clean_sweep_retrofit_scripts.md — widget annotation is a clean-sweep pattern (annotate once, roll up everywhere)
• feedback_qa_capture_pattern.md — widget UX parallel (drop-in pattern, lift across portfolio)
• user_compounding_signal_north_star.md — strategic frame this fits
• project_pa_claim_cockpit.md — adjacent surface that benefits first (money-map automation)

Anti-patterns to avoid

• Don’t build a database. The data lives in the HTML (annotations on already-authored content). No backend, no migrations, no auth surface. Static HTML stays the truth.
• Don’t auto-detect costs from prose. Regex-matching “$500” in body text is fragile + wrong (catches example costs in documentation, prose discussions, etc.). Require explicit data-cost annotations.
• Don’t render before DOM ready. Widget mounts on DOMContentLoaded so server-rendered annotations are all in place before the scan.
• Don’t use a SaaS solution. Same principle as the rest of the portfolio — git-tracked, plain HTML, no SaaS lock-in.

The aphorism

Annotate where the cost lives, render where the rollup is useful. The HTML is the database; the widget is the view.