The business unit ordered an externally developed automated cell without involving the software team. Haas engineers in Germany needed a stable API contract to build against while the production version was still being designed — and the proprietary production code could not be shared.

The scope was larger than initially described: beyond part sign-off and serial number retrieval, the API would need to directly command a Keyence laser marker and poll a Wenzel CMM for measurement results — hardware integrations that had to be negotiated and designed mid-project. Simultaneously, the Haas team in Germany needed something to develop against immediately, with no access to any of Turbocam's real infrastructure or data.

A minimal dummy API was built that matched the exact OpenAPI spec of the production version endpoint-for-endpoint, with Bearer authentication wired in identically. A lightweight HTML mock UI let the Haas developer simulate state changes on the CMM and laser marker — triggering the same async polling flow their controller would use in production. The whole thing was containerized into a single Docker image and emailed to Germany. On the production side, the layered architecture from the Keyence laser cell was extended: the laser marker communication library was reused as-is, and a new integration layer was added to command the Wenzel CMM and surface its results through the same request/poll API pattern the Haas controller expected.

When the machine arrived in the US, integration was completed in roughly a day. Architectural improvements back-ported cleanly to the previous cell generation, validated by existing unit tests with no regressions.

A major aerospace customer imposed strict requirements: laser parameters must be verified before and after every mark, with a full history linkable to individual part serial numbers. Existing systems were failing, isolated, and nearly impossible to maintain — a significant compliance and audit risk.

Keyence provided no .NET SDK, leaving the documented TCP wire protocol as the only integration path. At the same time, the software and Automation teams operated on completely different development timelines — waiting for the physical cell to be ready before testing any server logic was not an option.

The TCP protocol was implemented from Keyence's communication manual as a parameterized template engine: a method accepts a message template and a parameter dictionary, interpolates values into the wire format, sends to the UTF-8 TCP stream, and parses responses back out by matching against a corresponding response template. This made implementing the full command set fast and nearly bug-free. To decouple development from the physical cell, a software-in-the-loop (SIL) testing approach was built using C# source generators: generated stub classes mirrored the real PLC's tag interface, letting the full control logic be exercised against a simulated PLC in unit and integration tests. State transitions, fault paths, handshake sequences, and timeout behavior were all validated from the test harness long before any hardware was available — and the same stubs were swapped for live PLC clients in production with no changes to the control code. When the real machine was first connected, the software worked correctly within a single day.

Significantly improved traceability, resolved the failures caused by legacy systems, and built enough customer trust to justify a second identical cell and a follow-on automated cell project. Audit logs reliably correlate laser parameters to individual parts for any future quality investigation.

A top aerospace customer mandated that all parts conform to a specific drawing revision by a hard deadline. The business unit had millions of dollars of stock inspected to older revisions. Failure to meet the requirement would have seriously damaged the company's most important customer relationship.

The naive approach — a lookup table mapping old features to new ones — broke down almost immediately. Bubble numbers changed between revisions, measurement types changed, some features had no equivalent in the new revision, some previously in-tolerance parts became out-of-tolerance on the new rev, and some new features had no historical data at all. No single heuristic could cover the space. Throughput was also a hard constraint: hundreds of thousands of parts needed to be processed under a tight deadline.

A graph-based specification map was designed in close collaboration with a senior Quality Engineer: each feature at each revision is a node, and edges encode the transformation rules between them. A breadth-first walk of the graph from any starting feature determines the exact sequence of changes needed to reach every corresponding feature on the target revision, including cases where features split, merge, or disappear. The processing pipeline was built on C# TPL Dataflow for parallel execution, with IAsyncEnumerable feeding parts in asynchronously. Workers hit only production APIs with no direct database access, which meant the process could be scaled horizontally by spinning up additional instances — critical for hitting throughput targets on the initial run of over a hundred thousand parts.

Launched on time. Millions of dollars of at-risk inventory was protected and the customer relationship was maintained. The scalable architecture supported the project's next phase with minimal rework.

Built to gain hands-on AWS and Kubernetes experience outside of work while solving a real personal need. The goal was to integrate multiple async data sources — bank OFX exports, manually uploaded receipts, and Textract OCR results — into a single coherent financial data model.

Three async data paths needed to converge into one consistent model: S3 event triggers firing Lambda functions, Textract jobs completing asynchronously, and OFX bank export files parsed on a separate schedule. IAM scoping and S3 event configuration both had failure modes that weren't obvious until they happened.

IAM roles were scoped tightly per service rather than using a single broad key, which forced explicit reasoning about each data path's permissions and made misconfiguration easy to spot. S3 event notifications trigger a Python Lambda that launches Textract and stores the parsed output. The homelab side runs on a two-node Raspberry Pi k3s cluster: a Cloud Native PG cluster for persistence, a Helm-deployed Grafana/Prometheus stack for visibility, and Redis for the finance app — all managed via Kustomize.

Fully operational in a two-node homelab. Provided the practical AWS and Kubernetes fluency that now informs professional architectural decisions.

Needed reliable wireless control over a long distance where WiFi was not viable. The project was also a deliberate exercise in implementing the full IoT stack from cloud broker down to the RF physical layer.

Packet framing, error handling, and status feedback had to be implemented in CircuitPython, where available memory is measured in kilobytes and standard library support is minimal. The bridge device also had to maintain a reliable SSL WiFi connection to Adafruit IO while simultaneously managing the LoRa radio link — two very different communication stacks running on a microcontroller.

A simple fixed-length packet format was designed for the LoRa link that could be parsed with minimal memory allocation. The Feather M4 runs a tight polling loop: check Adafruit IO for state changes over SSL, encode any change into a LoRa packet, transmit, and wait for an acknowledgment from the receiver before updating the broker.

The system worked as intended. The project deepened practical knowledge of the full IoT stack in a way directly applicable to robotics and automation work.

The Automation group requested three separate variants of an existing camera inspection app. Maintaining three codebases was unsustainable for a small team. Drawing on experience with hardware integration and modular software design, the goal was a plugin-based orchestration engine — one that would let automation engineers modify process logic in seconds without a code deployment.

The runtime needed to be genuinely expressive: Routines required conditional branching, scoped variables, and inline math/string expressions — enough power to replace real code without requiring users to write any.

A lightweight AST expression parser was built from scratch, supporting basic math with correct operator precedence and string interpolation against the active Data Context. The Data Context itself uses a hierarchical parent-scope lookup — similar to lexical closures — so variables declared at the application level are accessible inside Routines, while Routine-scoped variables stay isolated. Together these gave the workflow designer the expressive power of a simple scripting language without any external dependency.

Supports automated production of aluminum impellers across the facility. Process changes by automation engineers now take seconds instead of days. The plugin architecture was reused directly in the Haas Automation cell project with no structural changes.

CognexParser was a monolithic app with no integration points. Three different cell configurations needed to be served without maintaining three separate codebases. Refactoring it into an Automato plugin was the path to covering all variants from one deployable.

The plugin had to handle single-camera, dual-station, and future multi-camera configurations. Each station needed to reliably open full-screen on a specific physical monitor — a requirement that had to survive reboots, display order changes, and varying hardware setups across different cells.

Windows APIs were used to query live display geometry at runtime. The settings pane renders a diagram of the detected monitors; clicking one assigns a station to it. That assignment is persisted in the plugin configuration so the station always opens full-screen on the correct display, regardless of how the OS enumerates monitors on startup. Multi-camera multiplexing was also built in as a latent capability — the configuration model supports it without surfacing complexity to users who don't need it.

One plugin configuration covers all known cell variants in production. Latent multi-camera support is built in, ready for future cycle-time improvements without a code change.

Finance staff were manually copying data between inventory kiosk reports and ERP forms every day — an error-prone, time-consuming process with no audit trail.

Each ERP upload required multiple sequential API calls per line item: part lookup, job lookup, inventory prefetch, and a bin transfer to complete the tooling-to-job assignment. An initial deep-call-stack design — where each step internally called the next — produced enormous, nearly unreadable stack traces when any step failed, making errors nearly impossible to attribute or debug.

The call stack was flattened into a pipeline architecture: each ERP step became a discrete class that received a line item object, performed one operation, appended a result status, and returned. The orchestrator passed each item through the stages in sequence and collected failures without any step knowing about the others. This made the failure surface immediately obvious and the code straightforward to extend. Per-item state and a full retry history were persisted in SQLite, with filename-to-datetime parsing used to detect and skip already-processed files without a separate tracking table.

Deployed across multiple buildings. Up to 10 hours of manual labor saved per week. The daily HTML report became a cornerstone of several managers' workflows.