Tell me what you want to build, automate, or improve.

Software and workflow automation, backend and integration systems, and the release and validation tooling that makes both repeatable. More recently, AI-assisted product development — building with AI in the loop, and building systems that put AI to work.

The through-line is operational. Most of what I build starts as something a team already does by hand — a reporting process, a release check, a piece of knowledge only one person holds — and ends as a system that does it dependably, with the failure modes handled deliberately rather than discovered in production.

Twenty years and counting, currently as a Senior Staff Software Engineer.

It started in semiconductor physical design and design-for-manufacturing, moved into design automation and methodology, then into production engineering on systems where an outage was measured in money. The last decade has been software architecture and automation platforms: the tooling engineers depend on to get their actual work done.

That path is why I tend to think about operations first. Twenty years of owning things that run teaches you to design for the day they do not.

Both, and the combination is the useful part.

I have architected and delivered enterprise automation platforms from a blank page — execution frameworks, workflow monitoring, credential management, measurement and analysis tooling — and then owned them in production afterwards as the technical point of contact when something broke.

Building something and then living with it for years changes how you build the next one. It is the difference between a system that demos well and one that is still maintainable after three people have handed it on.

AWS mainly, and it goes back further than most people expect — my first cloud work was running EDA workloads on cloud infrastructure in 2011, when that was still an unusual thing to do.

In practice that has meant queue-driven architectures with dead-letter handling (SQS), serverless compute behind an API gateway (Lambda), object storage with presigned access (S3), instance-based workers (EC2), and the identity side people tend to skip — IAM auditing, least-privilege roles, and access-key rotation.

Most recently I have built a working orchestration toolkit of exactly that shape: an API gateway front door into Lambda, queue dispatch out to EC2 workers, results in object storage behind presigned URLs, signed requests, dead-letter handling, and health and heartbeat checks. A demonstration of it is being prepared.

I have also worked with Google Cloud, and with the layer underneath that nobody puts on a slide — Linux, NGINX, Apache and Django in production, plus the monitoring and incident response that comes with owning something that runs.

In-house, across roughly two decades: Synopsys, GlobalFoundries, NYSE Euronext, Plunify, Chartered Semiconductor, and Intel.

Alongside that I have taken freelance and consulting work throughout — system administration, web development, and custom application builds for smaller clients — and I still take on independent development outside of employment.

The work published on this site is separate from all of that. It is personal — built on my own time, for my own reasons — and none of it came out of a job. Anything I built for an employer stays with the employer, and where I refer to it at all I describe the problem and the approach rather than name the system.

Some of it, yes. My public repositories are available at github.com/crismag.

Where an entry on this site includes a source link, the repository is public and you are welcome to explore it. Where it does not, the work is proprietary, private, or otherwise not appropriate to publish.

All of it is personal work, written on personal time. None of my repositories come from an employer, and a project appearing here in the same years as a job is a coincidence of calendars rather than a connection.

My public repositories include projects, experiments, tools, prototypes, and active development. They are useful for seeing not only finished code, but also how ideas evolve into working systems.

Yes, and some of it is the work I am most attached to.

The main one is a church management and ministry platform I build and maintain — member management, event RSVP and sign-up, ministry scheduling, and the reporting that ministry teams actually have to produce. It is in continuous real-world use, and it is given rather than billed.

There is usually something smaller alongside it: tools for people who need something that works and have no budget for it. That is often where the most interesting constraints are, and where you find out quickly whether a design survives contact with people who did not ask for software.

This is not a full list — just what is current.