Reporter Case Study: Turning Haunted Excel Sheets Into Dashboard Signals

The spreadsheet had grown teeth

Every team has one.

The spreadsheet that started innocent.

At first it was a simple tracker. A few rows. A few columns. A color-coded status field because humans enjoy pretending color is governance.

Then someone added another sheet. Then a formula. Then a weekly report tab. Then a pivot table. Then a copied version for the manager. Then a second copied version because the first copied version was “not final.”

Soon the file had tabs named:

Summary
Summary_New
Final Summary
Final Summary 2
DO NOT TOUCH
Use This One
Use This One Real
Archive_old_maybe

At this stage, the spreadsheet is no longer a document.

It is a haunted apartment block.

People still live there. Nobody understands the wiring.

Reporter came from that kind of pain.

The problem Reporter was built around

Teams often spend too much time cross-checking worksheets before sharing performance updates.

The data exists.

That is not the problem.

The problem is that the data is scattered across sheets, formats, exports, and manually maintained relationships.

Someone needs to answer:

Which campaign performed better?
Which region is dropping?
Which trainer group improved?
Which sales source has better conversion?
Which sheet has the correct number?
Why does this total not match the other total?
Who changed this formula and why is it smiling?

This is not glamorous analytics.

This is workflow archaeology.

Reporter was designed as a dashboard helper that turns Excel sheets into useful visual readouts and correlates data between worksheets.

The goal was simple:

Reduce repetitive analysis by creating clean dashboard views with sheet-to-sheet correlation.

Or in Bongbetic language:

Let the spreadsheet confess without making a junior analyst dig through twelve tabs with a candle.

The product shape

Reporter is best understood as a desktop analytics workbench.

Not a giant BI platform. Not an enterprise altar. Not another dashboard where you spend three days connecting data before discovering the export button is decorative.

Reporter was built around a smaller question:

What if someone could import sheets, map relationships, create visual widgets, and produce clean dashboard views without rebuilding the entire reporting universe?

The existing technical architecture describes Reporter as a cross-platform Electron desktop workbench with a React/TypeScript renderer, Zustand state management, Recharts and grid layouts for dashboards, DuckDB/xlsx/PapaParse for ingestion and manipulation, plus AI provider support through OpenAI, Anthropic, Gemini, and Ollama.

That means Reporter sits in a practical middle ground:

more structured than raw Excel chaos;
lighter than a full enterprise BI stack;
offline-friendly enough for desktop workflows;
flexible enough to compose visual dashboard widgets;
AI-aware without letting the AI run the building unsupervised.

What Reporter needed to understand

A reporting tool does not only need to draw charts.

That is the easy part.

A chart is just a picture with opinions.

The harder part is understanding data relationships.

Reporter needed to handle:

CSV input;
XLSX input;
Google Sheets public-share imports;
normalized dataset metadata;
multiple datasets;
calculated columns;
joins and relationships;
dashboard widgets;
chart-ready outputs;
table outputs;
settings and persistence;
export workflows.

This is where many reporting workflows break.

People do not merely need “a chart.”

They need a chart that reflects the correct sheet, the correct filter, the correct join, the correct time period, and the correct definition of “active,” which somehow changes every quarter and arrives in Slack as a sentence beginning with “Actually.”

Reporter was built to reduce that fog.

The AI assistant problem

Adding AI to analytics sounds attractive.

It also sounds like the opening scene of a small disaster.

An AI assistant in a dashboard tool might suggest charts, explain metrics, summarize data, or help build widgets.

Useful.

But if it can act too freely, it may:

invent relationships;
misread columns;
summarize stale data;
suggest meaningless charts;
overfit patterns;
hide uncertainty;
produce confident nonsense in executive language.

Executive language is especially dangerous because nonsense wearing a suit can survive several meetings.

Reporter’s technical design included provider routing, structured widget suggestions, tool-call filtering by autonomy level, and store-aware context sharing.

That matters.

The AI should help interpret and assemble.

It should not be allowed to quietly become the dashboard’s unelected finance minister.

The architecture lesson

Reporter taught Bongbetic an important product lesson:

Workflow tools need boundaries before they need intelligence.

The stack can be modern. The UI can be clean. The assistant can be smart.

But if the tool cannot control what data comes in, what transformations happen, what the assistant can change, and what gets exported, the user is still trapped in a prettier haunted spreadsheet.

Reporter’s architecture used:

Electron main process for secured IPC handlers;
preload bridge for controlled renderer APIs;
React/TypeScript renderer for dashboard state;
shared type contracts to align message formats;
ingestion utilities for CSV, XLSX, and Sheets;
constrained AI tooling helpers;
tests across aggregation, joins, formulas, trendlines, and AI-related helpers.

This is not just engineering trivia.

It is product philosophy.

A workflow tool should make the right thing easier and the dangerous thing harder.

That is the whole game.

Everything else is a pricing page.

Why Reporter belongs in Lab Notes now

Reporter is not currently the main commercial focus of Bongbetic.

The primary site direction now centers around:

vibe coding education;
Scrappy for lead generation;
SEO Bongbetic for Google-grounded SEO diagnosis;
BONGT for terminal and agent workflows;
VnAAI for voice, accent, transcript, and rubric coaching;
upcoming developer tools for memory, RAG, and lead workflows.

Reporter still matters because it explains where Bongbetic’s thinking comes from.

It is evidence that Bongbetic understands messy workflow systems, not just clean demo pages.

Spreadsheets are where many business problems reveal themselves.

They are also where many business problems hide after pretending to be solved.

Reporter belongs as a case study because it shows Bongbetic’s instinct:

find repetitive pain;
understand the workflow shape;
build a focused tool;
keep data visible;
add AI carefully;
export useful outputs;
avoid platform bloat where possible.

That instinct carries into every Bongbetic tool.

Scrappy does it for lead extraction. SEO Bongbetic does it for page-level SEO diagnosis. BONGT will do it for terminal workflows. VnAAI does it for voice and rubric coaching.

Reporter was one of the earlier rooms in the basement.

The basement got better because of it.

What builders can learn from Reporter

1. Start from the workflow, not the feature list

“Build a dashboard” is not enough.

Ask:

Who uses it?
What data do they import?
What decisions do they make?
What do they currently cross-check manually?
What errors happen repeatedly?
What output do they need at the end?

A feature list is a pile of bricks.

A workflow is the house.

Try not to confuse them unless you enjoy living under bricks.

2. AI should be constrained

AI assistance is useful when it has the right context and clear permissions.

It becomes risky when it can modify too much, invent too freely, or hide uncertainty.

For data tools, AI should explain confidence, cite columns, show assumptions, and leave a clear trail.

If the AI cannot explain where a chart came from, the chart should not be allowed near a meeting.

3. Exports matter

A dashboard is not always the final destination.

People need to share:

HTML;
images;
workbooks;
presentations;
summarized outputs;
structured files.

The export is often where the workflow actually delivers value.

If a tool creates insights but traps them inside itself, it is not a tool.

It is a decorative cage.

4. Offline-first thinking still matters

Not every workflow should depend on a heavy cloud platform.

Desktop tools can still be valuable when users need local control, file-based workflows, and fast interaction with messy data.

Cloud is powerful.

But sometimes the file is already on the machine, the meeting is in twenty minutes, and the Wi-Fi has entered its villain arc.

5. Tests are not optional

Reporter included tests across data operations and AI tooling helpers.

That matters because reporting errors are quiet.

A broken button is obvious. A wrong number looks professional.

Wrong numbers with nice charts are among the most dangerous objects in business.

They travel well.

The Bongbetic conclusion

Reporter was built to make spreadsheet-driven reporting less repetitive, less manual, and less haunted.

It did not try to replace every analytics platform.

It tried to solve a specific pain:

Turn sheet data into clearer dashboard signals and reduce cross-checking misery.

That is the Bongbetic pattern.

Small tool. Specific job. Practical output. A little darkness around the edges because the workflow was already dark.

The spreadsheet had grown teeth.

Reporter did not kill it.

Reporter taught it to speak.

Next step

Want tools built around actual workflow pain instead of dashboard cosplay?