Heartloom

Selected technical work

Things I have built

I keep returning to the same kind of work: find the point where a useful system becomes hard to operate, make its state and choices visible, and leave a path another person can inspect.

These three projects move from an Android terminal, through GitHub and repository workflows, into offline-first embedded firmware. The environments are different, but each one asked me to understand an existing way of working before deciding what to automate.

The individual case studies show what I built, the decisions behind it, how I checked the work, and what is still unfinished.

Current selection

Three different systems, one practical thread

Termux Dashboard project selection running in a tmux workspace on an Android phone

Mobile and local-first developer tooling

Usable alpha Public-readable

Termux Dashboard

A phone-friendly way to open the right project and return to an existing terminal workspace with one command.

The problem
Development from an Android phone loses momentum when reopening the right repository, remembering its state, and rebuilding a terminal workspace takes too many steps.
What I made
I wrote the shell entry point, the tmux window flows, the project and script menus, the Git safeguards, the user-local state behavior, the documentation, and the repository's lint and smoke-test paths.
Why it mattered
A short phone session can become useful work instead of setup time. The workflow stays local and inspectable, and it works with the terminal tools I already depend on instead of putting them behind another hosted service.

The repository is public to read, but it does not currently include a license granting reuse rights.

Read the case study View Termux Dashboard

Repository and workflow automation

Experimental Open source

Repo Automation Template

A set of terminal-first workflows that make careful GitHub and Codex work easier to repeat from a phone or computer.

The problem
Branch setup, AI handoffs, CI review, releases, and pull-request finishing are easy to perform inconsistently, especially when I am working from a phone.
What I made
I created a documented library of shell helpers with plan-first checks, machine-readable metadata, shared configuration, focused contracts, and a test harness that exercises Git and GitHub behavior with temporary repositories and stubbed network calls.
Why it mattered
The helpers reduce repeated maintenance work while keeping important choices visible. They give me a consistent way to work from a phone or computer without treating every repository as identical or trusting an opaque automation layer.

Licensed under Apache-2.0. The public helper surface is still stabilizing.

Read the case study View Repo Automation Template

Embedded and offline-first firmware

Paused Open source

ESP32 NFC Security System

An implemented firmware foundation and technical contracts for an offline-first workshop system using NFC and a local mobile interface.

The problem
The workshop needed a control system with clear operating states, local interfaces, and useful event records without depending on a cloud service.
What I made
I organized the specification and build sequence, then implemented the M0-M5 firmware foundation: build and flash layout, configuration and setup, time and storage handling, event logging, the state machine and outputs, and sensor handling. I also configured automated compile checks and wrote the bench checklist that later physical work must satisfy.
Why it mattered
The useful result at this stage is an inspectable architecture that names states and faults, keeps core operation local, and makes missing hardware visible. It is also a clear example of stopping short of a real-world effectiveness claim when physical work is unfinished.

Licensed under Apache-2.0. Later milestones are paused before bench testing resumes.

Read the case study View the firmware repository

A note about status and reuse

What the labels mean

Open source
The linked repository has a license that grants reuse rights. Read that repository’s license for the actual terms.
Public-readable
You can read the source, but the absence of a license means I am not granting reuse rights.
Usable alpha
The project works for real use, although installation, interfaces, or documentation may still change.
Paused
Meaningful work has been implemented, but later milestones or physical testing are not moving right now.

A real conversation

Tell me what you have in mind

I read these emails myself. Tell me what you are making, changing, exploring, or trying to repair. It helps to include:

  • what already exists and what is not working
  • what you want to change or make possible
  • the timing and approximate budget or exchange you have in mind
  • whether location, travel, shipping, or access to a hardware bench matters

Reaching out does not commit either of us to working together. It simply gives us a place to begin.

Email Schuyler GitHub LinkedIn