Finance → Data → Systems → Decisions
I build local-first systems that turn messy financial and operational evidence into reconciled state, reusable data infrastructure, and decision-ready analytics.
I started by building for the web, moved into full-stack products, found Python through analytics, then kept following the data until the scripts became pipelines and the pipelines became systems.
In parallel, Chartered Accountancy kept teaching me to ask annoying-but-useful questions:
Where did this number come from? What evidence supports it? Does it reconcile? What changed? Can I explain it later?
Eventually finance and engineering stopped being separate tracks.
flowchart LR
WEB["I · Product Engineering<br/>Vue · React · TypeScript<br/>Node · APIs · Databases"]
ANA["II · Analytics Engineering<br/>Excel · Power Query · Power BI<br/>Python Automation"]
DATA["III · Data Systems<br/>Polars · SQL · ETL<br/>Contracts · Semantic Systems"]
FIN["IV · Finance × Systems<br/>Control Plane · Quant<br/>Tax · FIRE · BI"]
WEB --> ANA --> DATA --> FIN
CA["Chartered Accountancy<br/>Accounting · Tax · Controls<br/>Evidence · Reconciliation"] --> X["Finance × Engineering"]
ANA --> X
DATA --> X
X --> FIN
Build products → engineer data → model semantics → reconstruct financial truth → support decisions.
|
My flagship: a local-first financial data engineering and quantitative decision-support platform. I use it to turn fragmented household, broker, market, FX, and reference evidence into one reconciled financial state that supports investment accounting, tax preparation, wealth analytics, FIRE planning, and Power BI. Evidence & data engineering Finance & Quant Tax, wealth & planning Reliability & product The fun part is that none of those subsystems gets to invent its own financial truth. 😄 |
⚡ PyQueryPython-native data execution systems. What began as Power Query-style transformation tooling evolved into reusable local-first data infrastructure. Current core Platform evolution What it proves |
Each of these sits on a different part of the path. I prefer that to a portfolio where twelve repositories all prove I can make another CRUD app.
|
Power BI semantics → reusable data infrastructure Extracts a Power BI semantic model, reconstructs it in relational SQL, then layers local semantic/RAG capabilities over that state.
Signal: BI semantics, metadata engineering, relational reconstruction, local AI. |
Python engineering inside real Excel workflows A modular Python × Excel × VBA framework for UDFs, query helpers, Power Query functions, and reusable analytics utilities.
Signal: pragmatic automation where business workflows actually live. |
|
Analytics engineering turned into a product An interactive synthetic-data workbench for finance and operations POCs, dashboard testing, modelling, and prototyping without exposing real client data.
Signal: analytical product design, safe prototyping, configurable data generation. |
A local systems-engineering side quest An open-source, memory-conscious take on Windows Recall built around local multimedia processing.
Signal: multimedia pipelines, resource constraints, privacy-first local systems. |
Also in the analytics-tooling lane: xl-pq-handler, where Power Query assets become maintainable engineering artifacts instead of mysterious workbook archaeology.
These projects matter because they show where the systems instincts came from.
|
A Vue-based Google Drive indexing product with backend services, authentication, role-based access control, MongoDB, media handling, and deployment tooling.
250+ stars · 230+ forks Open-source product engineering before data systems became the main plot. |
A full-stack personal-finance application built across 400+ commits in separate frontend and backend repositories. Frontend Backend This was where finance and product engineering first started sharing the same codebase. Personal Finance ETL is what happened after I kept asking harder questions of the data. 😅 |
Different projects, same recurring instincts:
flowchart LR
E["Preserve evidence"] --> S["Model semantics"]
S --> C["Make contracts explicit"]
C --> R["Reconcile state"]
R --> D["Serve decisions"]
D --> P["Preserve provenance"]
P --> E
- Evidence over convenient assumptions. If two states disagree, I would rather model the disagreement than silently make the dashboard prettier.
- Grain before metrics. A correct formula over the wrong financial object is still wrong.
- Local-first when the data deserves it. Personal and client-sensitive workflows do not need a cloud platform merely to feel sophisticated.
- Different workloads deserve different compute models. Vectorized ETL, stateful FIFO, numerical Monte Carlo, BI serving, and UI orchestration do not need one abstraction to win every argument.
- Generalize from working systems. I prefer abstractions extracted from real variation over frameworks designed for hypothetical futures.
- Delete complexity when it loses its job. Architecture should accumulate evidence, not barnacles.
| Capability | Toolkit / concepts |
|---|---|
| Data engineering | Python · Polars · DuckDB · SQLite · SQL · ETL · data contracts · lineage · reconciliation |
| Analytics & BI | Power BI · Power Query · Excel · DAX · semantic modelling · analytical marts |
| Software & product engineering | Pydantic · APIs · CLI · desktop apps · multiprocessing · TypeScript · React · Node.js |
| Finance & Quant | Accounting · controls · tax · FIFO · XIRR · portfolio analytics · FX attribution · Monte Carlo |
| Reliability & architecture | Deterministic identity · provenance · transactions · recovery · snapshot/restore · observability |
| AI & semantic systems | LangChain · RAG · Ollama · local LLM workflows · semantic metadata |
Chartered Accountancy is the domain lens, not a decorative credential. It shows up in how I think about evidence, reconciliation, controls, tax, grain, financial semantics, and whether a number can survive being asked “why?”
Stats are fun. Projects are the receipts.
Finance gave me the questions. Data gave me the structure. Software engineering let me build the answers.