Decisions first. Dashboards after.

ORIGIN MOMENT

The dashboard that nobody opened

Early in one of my engagements, I shipped a dashboard that was perfectly correct and almost entirely unused.

The data was clean. The charts loaded fast. The filters worked. The stakeholder thanked me on the demo call. A week later, nobody had opened it.

I asked one of the users why. The answer was that the dashboard told them what they already knew. The thing they actually needed to see, which competitor was likely to drop pricing next quarter, wasn't on the page because nobody had named it as the question up front. I'd built the request. Nobody had written down the need.

That was the moment "question before tool" stopped being a tidy phrase. Every project I take on starts with a written scoping document that names the business decision the work is meant to inform, before I touch a database. If we can't write that decision down together by end of week one, I'll say so and we won't start the build.

HOW SCOPING WORKS

The five questions I ask before any code is written

Every scoping call ends with five questions. The answers go into a one-page scoping document we both sign off on before week two begins.

1. What business decision is this work meant to inform? Specifically, what would you do differently with the answer than without it? If we can't articulate that, the project is premature.
2. Who is the one named decision-maker? One person whose sign-off counts. Committee approval stalls every project that runs through committee approval.
3. Where does the relevant data actually live, and who owns each source? Stripe, your app database, Google Sheets, an HR tool nobody remembers buying, a marketing platform with permissions tied to someone who left. All of it.
4. What did you try before, and why didn't it hold up? Failed prototypes are the best teaching material I have. They tell me where the real problem actually was, which is usually different from where you thought it was.
5. Who on your side will inherit the system after the engagement ends? If the answer is "nobody yet," we'll size the handoff differently. The system has to outlive me on your team.

If we can answer all five together by end of week one, the engagement is on rails. If we can't, the project isn't ready and we figure out what's missing before any code gets written.

PROOF

Public work, in five links

If you want to verify how I think before you book a call, start here.

1. Credit card fraud detection: ROC-AUC > 0.95, 84% recall at 0.28% alert volume. LightGBM classifier on a 284,807-transaction dataset with a 0.17% fraud rate. Production-shaped Streamlit dashboard with per-transaction explanations, action recommendations, and a business-impact calculator. The most production-shaped of my public projects. GitHub repo and live demo
2. Personal GraphRAG chatbot: Neo4j, Ollama, LangChain. A graph-based retrieval system over a personal knowledge base. Built so I could have an honest conversation with a founder about when graph traversal beats vector similarity, and when it doesn't. Vector RAG is still what I'll recommend most of the time. The build is what lets me defend the recommendation. GitHub repo
3. F1 driver behavior clustering on 2023 telemetry: K-Means and PCA over Monaco, Monza, and Silverstone telemetry data. Two driver behavioral profiles identified ("smooth drivers" and "aggressive brakers"), 85%+ variance preserved post-PCA. Deployed Streamlit dashboard. GitHub repo
4. Competitive intelligence dashboards at Wavess.io : ETL pipeline processing 520+ data points for fintech SaaS clients. Multilingual sentiment analysis on customer reviews. Reduced manual competitor research time by 70% for a sales team that didn't write SQL. Read the Dashboards service page
5. Medium and LinkedIn: Where I write up things I've shipped and patterns I'm seeing in the wild. Slower than Twitter. Deeper than a one-paragraph LinkedIn post. The Medium archive has the long form, the LinkedIn feed has the short form. Medium | LinkedIn