Skip to content

Software · Data · Operations

Software should remove work, not create more of it.

I lead engineering work and still write code. I talk with the people using the software, build the solution, and stay involved after launch.

Tools I use

  • Python
  • FastAPI
  • Prefect
  • Databricks
  • dbt
  • Delta Lake
  • Azure
  • PostgreSQL
  • React
  • TypeScript

Selected work

Production systems built around real operating problems.

  1. Secure strategic-customer portal

    Partnered directly with a strategic customer to design, launch, and operate a production multi-tenant portal for internal and external users. Turned a core customer's operating needs into secure production software with role- and relationship-based authorization.

  2. Production accounts-payable automation

    Designed, built, and continue to operate an AI-assisted workflow that combines document extraction, constrained classification, typed validation, IFS integration, and human review. AI handled 52% of first-week volume and reached a 65% daily automation peak while keeping deterministic controls around production decisions.

  3. Company-wide ETL architecture

    Designed and implemented a data ingestion architecture using Prefect, Python, and Delta Lake, reducing ETL processing time from hours to minutes across multiple acquired companies. 83% reduction in ETL processing time; real-time business intelligence without growing the team.

B2B customer-facing product

1,244 invoices in week one

83% faster ETL processing

Where I help

Useful when the problem crosses systems and teams.

  1. Make fragmented systems work together.

    Connect the data, applications, and operating processes that grew apart over time.

  2. Turn manual processes into maintainable tools.

    Reduce repetitive work without replacing it with fragile automation or hidden support burden.

  3. Move from architecture to dependable delivery.

    Keep the technical direction close to the code, the operators, and what happens after launch.

How I work

I care about what happens after launch.

I like problems where the software is only one part of the system. The best answers usually come from understanding the people, process, and constraints around it.

I default to simple tools, visible tradeoffs, and systems that are easier to operate after they launch, not just impressive on day one.

I write to make the reasoning visible: what worked, what failed, and what I would change next time.

Writing

Latest writing

Browse all writing

Connect

Working through a messy systems problem?

I am always happy to compare notes.

Connect on LinkedIn