← Zach Donnenfield
No. 03 systems product

Eleven tools analysts can change

I built eleven browser-based tools for recurring reporting, research, and outbound. Analysts define the report types; the tools handle the processing.

Outcome Recurring contractual reporting for two enterprise accounts now runs through the suite, and two analysts run the workflows on their own.

01 / Checked against delivered files 14 of 14 workbooks match, cell for cell

Monthly leaderboard build

By hand 25 to 35 hours
Automated run About 15 seconds

Verified by a round-trip regression script. Bars are to scale, except that the automated bar is widened to 3 pixels so it shows. The 15 seconds covers the run itself, not review and delivery.

Role
Solo. Architecture, build, design system, rollout.
Period
2025 to 2026
Team
Built with input from the analysts using the tools.

The same reports, rebuilt by hand every month

The services team assembled client deliverables by hand. They exported data, tagged creators one at a time, rebuilt 70-column leaderboards from raw files and put decks together slide by slide. Every new report type added another spreadsheet.

None of this was on a roadmap. I took it on because the same work came back every month.

Analysts own the report definition

A report type is a JSON file. An analyst writes one, imports it and runs the report, with no code change and no deploy.

Each tool is a single HTML file with no build step, and all eleven share one design system with accessible controls and print and PDF views. That kept shipping, checking and rolling back within what one person could handle.

02 / Report definition The analyst writes the file. The tool builds the report.

launch-tracker.json

"report": "Category launch tracker",
"brands": ["Fernwell", "Marlow", "Tidewater"],
"metric": "share of voice",
"compare": "prior month"

Generated report

Category launch tracker · June

Brand Share of voice vs. May
Fernwell 38% +4 pts
Marlow 27% −2 pts
Tidewater 21% +6 pts

Reconstruction. Invented brands and figures.

An AI request is an explicit boundary

Customer data is processed in the browser. It leaves only when an analyst asks for an AI step, which runs through a workflow engine. The aggregation engines check themselves against a known-good reference at startup.

Long jobs run in chunked queues with retries, and progress survives a reload. When a 120-second gateway timeout started cutting off long reports in production, I rebuilt the orchestrator within days so that it accepts the job and the tool polls for the result.

03 / Data boundary Local processing. An explicit route to AI.

Inside the browser / core reporting

  1. Check the engine Validate against a known-good reference.
  2. Process data Aggregate in the browser.
  3. Produce reports Prepare print and PDF views.
Optional / leaves the browser Analyst explicitly requests AI This action sends data to the workflow engine.
External service Workflow engine → AI call Core reporting works without this step.

The boundary applies to core report processing. AI calls use the external workflow; analytics Q&A also uses MCP.

Checked against what the client already had

The monthly leaderboard set had no written spec, so I rebuilt its method from the files the client had already received and checked the suite's output against every one of them. Rebuilding the method also exposed a 3.45% share overstatement in the old manual process.

Across the suite, I estimate the savings at 600 to 1,100 analyst hours a year.

What the design costs

Two analysts now run the reporting workflows without me, and a new report type is a file they can write themselves.

The tools share no server-side state, so a design fix has to be applied eleven times, and analysts correct their own configuration errors. I accepted that to keep the tools easy to ship and change.