About
I build and run the data systems behind provider contracting and claims processing at a large healthcare organization. In practice that means production SQL Server infrastructure, the pipelines that move contract and claims data between systems, the internal web applications people use to do that work, and the automation that keeps all of it from needing someone watching it on a schedule.
Most of my career has been spent on the operational side of data: server migrations and upgrades, reporting infrastructure, backup and recovery, scheduled jobs, and the reporting layer that leadership actually reads. The surrounding work is a mix of .NET web applications, Python and PowerShell automation, and SharePoint and Power Platform tooling.
I tend to end up owning the unglamorous parts. The refresh jobs, the health checks, the thing that breaks at six in the morning.
Enterprise SQL Server work gets treated as adjacent to data engineering. I would argue it is the same set of problems under older names.
When you own production, correctness is not a test suite. It is a phone call. That shapes how I build. Load jobs discover their own tables instead of carrying a hardcoded list, so nothing is silently skipped when the schema grows. Operations are ordered by dependency rather than by hand. Scripts that only belong on one environment refuse to run anywhere else. Anything that copies data finishes by reconciling what it moved against what was there, because a job that succeeds quietly and does nothing is worse than one that fails loudly.
The same instinct applies to knowing when something is wrong. Long before I had the vocabulary for observability, I was running scheduled checks for stale data, missing data, failed refreshes, and disk pressure, because nobody wants to hear from a stakeholder that a feed stopped three days ago.
What comes out of that is a bias toward systems that are boring on purpose. Predictable, re-runnable, and honest about their own state.
The properties that modern data platforms are organized around, things like idempotent reprocessing, handling corrected and late arriving records, lineage and versioning, and observability, are ones I have been solving in T-SQL and PowerShell for years. What I had not done was build them on the stack the rest of the field has standardized on. So I built something to learn it properly.
tickvault is a market data warehouse that ingests raw FX tick data and produces validated, queryable datasets. Python for ingest, Parquet for raw storage, dbt for the modeling layer, DuckDB for the served layer, and Dagster for orchestration.
I scoped it narrow on purpose so the interesting parts are the hard ones. Reprocessing a day without duplicating it. Handling a correction to data that has already been published downstream. Tracking where every row came from. Knowing when a load ran and silently did nothing. Design decisions get written down as I make them, tradeoffs included, because the reasoning is the part worth keeping.
The architecture and the decision log are on the Work page.
I care about the failure mode before I care about the feature. Most of what I have learned came from owning things in production long enough to see how they break.
I would rather ship something narrow that holds up than something broad that needs a caretaker. I write down why a decision was made, not just what was decided, because the reasoning is what someone needs six months later. And I assume the data is wrong in some way I have not found yet, which so far has been the correct assumption.
Regulated, audited, consequential data is the environment I know best. It is also the environment that taught me most of this.