Software Development

Backend systems in Go, Python, and Apex. APIs, ETL pipelines, event streaming, and healthcare data integration. Legacy modernization and full-platform migrations. CI/CD with CircleCI and Bitbucket, tests for everything I ship.

The problem: healthcare runs on software nobody wants to maintain

Most healthcare organizations I work with have the same set of problems. They run on systems bolted together over a decade. A Salesforce org with 300 custom objects nobody documented. An EHR integration that breaks every time the vendor pushes an update. ETL pipelines written by someone who left three years ago, held together by scheduled tasks and prayer. Reports that take 45 minutes to run because the queries were never optimized.

The real cost is not the tech debt itself. It is the compounding cost of working around it. Every new feature takes twice as long because you have to understand the existing mess first. Every outage takes longer to resolve because nobody knows which system owns which data. Every compliance question turns into a manual investigation because there is no audit trail.

And the people who built it are gone. The documentation, if it exists, is wrong. The test coverage is zero. The deployment process is "copy these files to the server." That is not a development practice. That is a liability.

How I build backend systems

I work in Go, Python, and Salesforce Apex. I choose the language based on the problem, not based on what I feel like writing that day. Heavy concurrency and low-latency APIs get Go. Data pipelines and orchestration get Python. Salesforce integrations get Apex. Sometimes a system needs all three.

APIs first

Every system I build starts with a well-defined API contract. OpenAPI specs for REST services. GraphQL schemas where the query flexibility matters. The API is the interface between systems, between teams, between what exists and what you need to build next. If the API is sloppy, everything built on top of it is sloppy.

I write the contract before I write the code. The client and server agree on the shape of the data, the error handling, the authentication, the pagination. Then I implement against that contract and write tests that verify the implementation matches it. When the contract changes, the tests fail. When the tests fail, you know something broke before it reaches production.

ETL that does not fall apart at 3am

Healthcare data pipelines have a bad reputation for being fragile. They break because someone changed a column name in the source system, or the file format changed from CSV to pipe-delimited, or the upstream system started sending dates in a different format. I build pipelines that handle these failures gracefully.

Schema validation on ingestion. Type coercion with explicit fallback rules. Dead letter queues for records that fail parsing so you do not silently lose data. Alerting when error rates spike. Retry logic with backoff for transient failures. The pipeline should not silently produce wrong output. It should fail loud and tell you exactly what went wrong.

Event streaming for real-time systems

Some problems need batch processing. Some need real-time. When a new clinical encounter lands in the EHR and three downstream systems need to react within seconds, you need event streaming, not a nightly ETL job. I build event-driven architectures with Kafka, event bridges, and change data capture feeds that propagate state changes across systems without coupling them directly.

Healthcare data integration

HL7, FHIR, CCDAs, proprietary vendor APIs. Healthcare data comes in formats that were never designed to work together. I have spent years writing the adapters, mappers, and transformation layers that make these systems talk to each other. The goal is always the same: get the data out of its silo, transform it into a canonical shape, and land it somewhere the rest of the system can actually use it.

Legacy modernization

Rewriting a legacy system from scratch is almost always the wrong approach. The system works. It is ugly, it is slow, and nobody understands it, but it works. You replace it piece by piece. Extract the business logic. Build a clean API around it. Route traffic to the new implementation. Decommission the old code when the new code has proven itself in production.

That is how I handled the Workday migration. Ten thousand workers, a pile of custom integrations, a hardcoded legacy system that nobody wanted to touch. I did not burn it down. I built the replacement alongside it, migrated incrementally, validated at each step, and cut over when the data matched.

What you get

Working code. Not a design document. Not a proof of concept that I hand off for someone else to finish. Production-ready software that runs in your environment.

• Tested code. Unit tests, integration tests, contract tests. Every PR runs through CI before it merges. If the tests do not pass, the code does not ship.
• CI/CD pipelines. CircleCI or Bitbucket Pipelines, configured for your repo. Automated builds, automated tests, automated deployment to staging. Manual approval gate for production.
• Documentation. Every API endpoint documented. Every pipeline documented. Architecture decisions recorded. Runbooks for operations. Not because documentation is fun, but because the next person who touches this code deserves to understand what it does and why.
• Version control. Everything in Git. Branching strategy that matches your workflow. Meaningful commit messages. Pull request reviews.
• Monitoring and alerting. You should know when something breaks before your users do. I set up health checks, error rate alerts, and pipeline status monitoring so failures do not go unnoticed.

Proof

19 years writing software. The last several focused on healthcare systems, data platforms, and integrations. Five-star ratings across every platform I work on. A Workday migration that moved ten thousand workers without losing a single record. A dbt data platform with 500+ models that feeds 30+ production dashboards. Full-platform migrations from Snowflake to Databricks, from Tableau to governed BI, from ad-hoc scripts to tested, documented, CI/CD-backed code.

I do not bid on projects I cannot deliver. I do not overpromise. I tell you what I can build, how long it will take, and what it will cost. Then I build it.