Hello world! My name is Matt.

About Me

---

I currently work at RxPost, where I was brought in to help move an existing pharmaceutical marketplace off an earlier Supabase-backed application and onto a more structured AWS environment. The job was framed as the data layer, but in practice I became the lead engineer on the CI/CD, data layers, and APIs as we carried the platform through to its launch on the new stack.

The database is PostgreSQL running on Aurora, and a lot of my time went into schema refinement, performance work, and deployment safety. I replaced ad-hoc SQL changes with a Liquibase-based CI/CD process, refactored keys, indexes, and constraints as the model matured. The APIs are Lambdas per route (definition mirrored Supabase at start) written in Node.js. I wrote out business logic, created DAO and service layers, and added tests at the unit, DAO, and contract level — the last using Schemathesis to check the API against its own spec. Lambdas, databases and other infrastructure are maintained IaC style via Terraform. GitHub Actions I created keeps us honest on PRs and standardized on deploys.

As part of my time here I built my own agentic engineering pipeline — a set of Claude Code skills that carry a change from planning through implementation, review, verification, and release. The team has shared versions of some of these; I kept tuning my own local forks to fit how I actually work. The requirements- and acceptance-criteria-validation skills were solid, useful but not unusual. The ones I'm most proud of are the demo-doc generators: a lot of my changes are backend and data-layer work with no front-end flow to click through, so there was never an easy way to show a stakeholder that something worked. These skills capture positive- and negative-path proof for a change, run it against the live stack, and turn it into a demo-ready writeup — which solved a problem I don't think most front-end-flow-driven teams ever have to.

Before that I worked at IQVIA in their Channel and Specialty Data Solutions department on the ValueTrak platform. ValueTrak is a business intelligence platform used by pharmaceutical manufacturers to gain insight into their supply chain. The product later expanded into MedTech devices and Specialty pharmaceuticals, which is about when I joined. The overall goal stayed the same, but the data sources and areas of focus changed.

I was there from 2015 through 2025 and held several roles along the way, moving from engineer to manager and back to senior individual contributor and architect work. In the later years I focused heavily on data platforms in Oracle, especially PL/SQL, where most of my work centered on ETL pipelines, data enrichment, performance, and keeping large systems behaving under real-world conditions.

The broader stack there was ColdFusion (Java-based) in the middle tier, with a lot of JavaScript/jQuery on the front end and newer work in React. I did most of my work in the database layer, but I got involved in the rest of the stack as needed. That is also where I fully accepted that databases are the part of software I understand best and enjoy most.

In between individual contributor stints, I managed a team of 10-15 developers across multiple customer segments. Along with coaching people technically, I owned quite a bit of SDLC automation through GitLab Pipelines, some Bash, a little Python, and a release tool written in Node.js. I also jumped into a side effort written in PHP with Laravel when it needed help.

From 2012-2015 I was at Synacor in Professional Services, doing customization and integration work around their white-label products. That was mostly backend and integration work in a proprietary PHP framework that felt a lot like Symfony, plus some reconciliation and database scripting in Perl.

From 2007-2012 I was at Real-Info. For four of those five years I was the only developer there, which made for a pretty strong first job out of school. We loaded data for more than 1,000 U.S. counties each month into a MySQL database that fed a membership site and their AVM products. I cannot take credit for the data or mathematical modeling, but I learned a lot about debugging, integration work, and squeezing more performance out of large data processes. At one point I made a set of changes that improved a heavy property-processing workflow by about 70%.