How I work

Start light. Upgrade when the data grows.

Most reporting problems do not need a platform, a migration, or a year. They need someone to build the specific thing, quickly, from the data you already have.

The trap in this market is being sold the biggest version of the solution on day one — a platform, a data warehouse, a per-seat licence, and six months before anyone sees a chart. I start at the smallest thing that answers the question, and move up only when the data actually outgrows it.

The three shapes

1 · A self-contained file

One HTML file, built from your spreadsheet or export, that you open from your own file share. Charts, filters, cross-filtering and drill-down all run in your browser. No server, no login, no install, nothing to subscribe to. It works offline and it works from a network drive.

Right when: the data is a manageable export — up to roughly 30 MB or 150,000 rows — and someone is currently rebuilding the same view by hand every week.

Refresh: you re-run it against a new export, or I rebuild it. This is the starting point for most engagements, and for plenty of them it is also the finishing point.

2 · An automated refresh

The same dashboard, but a scheduled job reads the source, aggregates it, and republishes the file overnight. It runs in your tenant on credentials you own. If a sanity check fails it keeps yesterday's good version rather than publishing something wrong, and it tells someone.

Right when: the file is bigger than a browser wants to chew on, or the manual step of dropping in a new export has become the bottleneck.

Refresh: nightly, or on whatever schedule matches how the decisions get made.

3 · An explorable dataset

For when the aggregates are not enough and people need to explore row-level detail themselves. The data is converted to a columnar format and queried by an engine running in the browser tab — so it still does not need a server, and the data still does not leave your environment.

Right when: the questions keep changing, and every new one currently means another request to someone.

And when none of these is right

Some problems genuinely do need a real data platform — many sources, streaming, multi-gigabyte data, a lot of people writing back to it. Perhaps one in five of the conversations I have. When that is the case I will tell you so, and either point you at someone who does that work or scope it honestly as a bigger project. Selling you a clever single file for a problem that needs a warehouse wastes your money and my reputation.

What an engagement looks like

A callTwenty minutes. What decision are you trying to make, what is the data, who reads the result. Free, and it sometimes ends with me saying you do not need me.
A sample fileYou send a representative export — real or redacted, your call. I confirm what is answerable from it and what is not, before either of us commits.
A fixed quoteA specific scope, a specific price, a specific date. Not an estimate that grows.
BuildUsually days rather than weeks. You see a working version early enough to change your mind about it while changing it is still cheap.
HandoverThe file, the source, the documentation, and — for anything automated — the runbook and a completed access register with every credential accounted for.

Pricing

Fixed price per engagement. You know the number before the work starts, and it does not move because something took me longer than I thought. That is my risk to carry, not yours.

An optional monthly retainer for changes, new views, and keeping an automated refresh healthy. Optional genuinely means optional — the deliverable keeps working if you never take it, because there is no licence and no server of mine involved.

Never a day rate. A day rate pays me for hours and pays you for nothing in particular, and it makes every efficiency I find into a pay cut. Fixed price aligns those.

The number depends on scope and I will not pretend otherwise, so it comes after the call and the sample file rather than off a menu. What I can tell you before then is the shape: one fixed number, one optional monthly one, and no third line.

What you own at the end

The full detail on access, residency, failure behaviour and what is held at the end is on the security & deployment page.

Twenty minutes, no pitch.

Bring the problem and, if you have one, a file. Worst case you get a straight answer about whether this is the right approach at all.

Book a call