I build backend systems, tools for working with agents, and the
infrastructure they run on.
Currently a software engineer at InvoiceCloud.
Based in San Antonio, Texas.
01
At work
InvoiceCloud / 2023–present
My work at InvoiceCloud spans payment processing, funding, and
internal tools. The common thread is making systems easier to
understand and dependable to operate.
Internal support platform
Watchtower
Some support questions can only be answered by connecting
several pieces of the business: what the code does, what
happened in production, and what a customer is experiencing.
Those questions used to require an engineering handoff.
I created and led development of Watchtower, a .NET 10
platform that brings those sources into one investigation. Its
agent combines code relationships and live source inspection
with production telemetry, customer context, and allowlisted
database access.
A separate indexing pipeline brings in internal documentation,
issue tracking, and source-control content for semantic
search. That gives the platform both written knowledge and
tools to investigate the running system.
A question, followed through the systemConceptual architecture
Watchtower is a modular monolith. The platform brings
source-code investigation, indexed knowledge, and operational
integrations together while keeping their responsibilities
separate.
Microsoft Agent Framework tooling exposes the code graph and
investigation tools to the agent. Database access is
allowlisted, giving the investigation a defined set of
operational data to work with.
Searching for a symbol is useful. Understanding how it fits
into an unfamiliar repository takes more context.
I created KOBRA, a Python pipeline that indexes all
InvoiceCloud repositories and extracts C#, VB.NET, and T-SQL
symbols into a PostgreSQL-backed code graph. Watchtower uses
that graph alongside live source inspection to follow code
relationships during an investigation.
Python / PostgreSQL / C# / VB.NET / T-SQL
The payment systems underneath
Alongside these platforms, I develop and maintain .NET payment
processing and funding systems: data ingestion, exports,
production monitoring, and alerting. Correctness, performance, and
auditability shape that work.
02
On my own
Independent projects
A few projects where I can follow a question all the way through:
how agents use development environments, how people share a visual
workspace, and what makes those tools usable.
Development environments
Wisp
Project coordination needs to outlive the environment doing the
work. Wisp pairs a persistent coordinator with disposable
container workspaces, where agents can run commands, edit files,
and use development tools.
Docker and Sysbox provide the workspace environments. Project
context stays available as individual workers are stopped or
replaced.
A performance detail +
Long conversations made the initial page expensive to
render. Incremental history rendering reduced initial DOM
elements from approximately 19,400 to 1,350 in a production
browser check, while keeping earlier messages accessible.
A pixel-art and animation workshop with two ways in: people draw
in the editor, and agents draw through a structured HTTP API.
Both see the same artwork update live.
The editor supports layers, palettes, onion skinning, and frame
timing. Agents can preview an operation before committing it,
inspect ASCII or PNG output, and export a sprite sheet with
animation metadata.
Keeping shared edits consistent
+
Drawing operations run as an atomic batch against a copy of
the document. The complete result is validated before being
saved and broadcast. Revision checks reject stale edits so a
person and an agent cannot silently overwrite each other.
Projects persist to disk. A shared viewer URL grants read
and export access; a separate write token controls changes.
Live updates travel over Server-Sent Events.
A workspace for pixels, frames, and agents.Illustrative sprite
Visual explanations
Agent Canvas
A shared surface for explaining a system as it unfolds. An agent
sends small HTTP updates; people watch boxes, connections,
highlights, and explanations appear in the browser.
Flow diagrams show relationships. Sequence diagrams show
requests and messages over time. Automatic layout handles
positioning, while live updates preserve the viewer’s zoom and
pan.
Disposable by design +
Canvases live in memory and expire 24 hours after their last
successful write. JSON export preserves a snapshot. This
keeps the tool focused on a live explanation rather than
maintaining a permanent document library.
Updates are atomic and broadcast over Server-Sent Events.
Viewer URLs can be shared without revealing the separate
write token.
One request, explained a step at a time.Illustrative sequence diagram
03
Behind the apps
Self-hosted infrastructure
The work continues after deployment.
I operate Linux servers for my own applications and supporting
services. It gives me a place to work on the parts of software
that are easy to miss in a local development environment:
routing, certificates, image delivery, persistent data, and
recovery.
The projects above run on this infrastructure. Running them
means following through on what happens after a build succeeds.
a.
Build & release
Woodpecker CI builds container images from GitHub and
publishes commit-tagged versions to a private registry.
Applications run as Docker Compose stacks, with pinned image
versions for deployment and rollback.
Woodpecker CI / Docker / Private registry
b.
Routing & access
Traefik routes public HTTPS traffic to application containers
and manages Let’s Encrypt certificates. Private services use
LAN or Tailscale access, keeping their access model separate
from public applications.
Traefik / TLS / Tailscale / Linux
c.
Observability
Grafana and VictoriaMetrics bring host metrics from two
servers into one place. VictoriaLogs collects system journal
logs from the application host, making resource usage and
system events available for investigation.
Grafana / VictoriaMetrics / VictoriaLogs
d.
Data & recovery
Wisp’s scheduled backups capture consistent database
snapshots, configuration, and recovery keys. Each run includes
an isolated restore check. A manual off-host copy has also
been restore-tested.
SQLite backup API / systemd timers / Restore verification
04
Background
The path here
I’m based in San Antonio, Texas, and graduated from Texas State
University with a B.S. in Computer Science in December 2022.
Before working on backend systems, I helped people diagnose and
repair their devices at Geek Squad. That experience still
matters when I’m building tools: someone needs to understand
what happened and what to do next.