# Story

I did not get into software through the normal pipeline.

I studied law, practiced intellectual property litigation, and spent years
learning how to read dense systems under pressure, write precisely, and make an
argument hold up when the room is hostile.

That training never left. I just switched mediums.

## Law Taught Me the Shape of Good Work

Litigation taught me to care about edge cases, language, evidence, and failure
modes.

It also taught me that most systems are held together by institutional habit,
not by good design.

That instinct still shows up in how I build:

- understand the actual constraint
- find the real source of truth
- remove theatre
- ship something that can survive contact with users

## Then I Started Building

After law, I moved deeper into software by doing the only thing that really
counts: shipping.

I built products under financial pressure, launched full-stack apps, sold them
myself, and learned the useful version of product work: not the slide-deck
version, the version where the thing either works or it does not.

That stretch hardened a few preferences:

- speed matters
- taste matters
- code should reduce friction, not manufacture new ceremony
- the shortest honest path usually beats the more "scalable" fantasy

## Operator Brain, Builder Hands

At Wiom I worked on product, data, ML, automation, and delivery problems that
had to function inside real operational mess.

I have spent a lot of time turning rough, partially documented, business-critical
systems into working products and decision surfaces.

That included work like reverse-engineering an undocumented core algorithm after
the original builder left, collapsing five legacy systems into one JSON-driven
platform, and shipping AI-assisted operational tooling that had to work in the
real world instead of in demos.

That work sharpened a part of me I trust:

- I like ugly problem spaces.
- I like legacy systems with missing context.
- I like translating operational pain into software that people can actually use.

## The Pain I Trust Most

The problems I trust myself on now tend to look like this:

- the workflow is real, but it is scattered across tabs, spreadsheets, and
  tribal knowledge
- the actual source of truth is blurry or trapped inside one operator's memory
- the current tool adds ceremony instead of reducing it
- people need speed and clarity, not another layer of software

I like that kind of mess. It rewards directness.

## Public Tools Matter More to Me Than Portfolio Theatre

A lot of my public work is me refusing to accept bloated software as normal.

I do not think most daily software pain comes from missing features. I think it
usually comes from the wrong container, the wrong interaction model, and too
much ceremony around simple tasks.

Instead of collecting "projects" as portfolio props, I keep building tools I
actually want:

- `gmail` -> repo: https://github.com/ryangerardwilson/gmail | because webmail
  turns triage into tab management, multi-account state, and inbox theatre
- `gdrive` -> repo: https://github.com/ryangerardwilson/gdrive | because backup
  should not feel like trusting a browser upload widget and remembering what is
  authoritative
- `tm` -> repo: https://github.com/ryangerardwilson/tm | because tmux workflows
  too often live as private shell folklore instead of a maintained product
- `o` -> repo: https://github.com/ryangerardwilson/o | because "show in folder"
  should not dump me into a mouse maze when I already live on `hjkl`
- `vixl` -> repo: https://github.com/ryangerardwilson/vixl | because large
  spreadsheets become slow, opaque, and visually noisy long before the work is
  actually hard
- `gvim` -> repo: https://github.com/ryangerardwilson/gvim | because I wanted a
  richer document surface than raw markdown without surrendering Vim to Word or
  browser-note slop
- `xyz` -> repo: https://github.com/ryangerardwilson/xyz | because most task
  systems reward anxiety, list grooming, and fake productivity instead of real
  outcomes
- `erza` -> repo: https://github.com/ryangerardwilson/erza | docs:
  https://erza.ryangerardwilson.com/ | because some docs and tools belong in
  the terminal entirely, not in tab sprawl dressed up as modern UX

`erza` is the clearest expression of where my taste is heading now: a
terminal-native UI language and runtime for docs, tools, and small product
surfaces, plus a remote protocol that lets those surfaces live beyond one local
Python app.

It started from a blunt frustration: remote docs and lightweight tools keep
pretending they need browser chrome, cookie banners, popovers, and a tab slot.
I want a world where a remote surface can be opened as `erza example.com`,
stay keyboard-first, and feel as direct as a local terminal app.

This public repo trail is the cleanest way to understand me:
https://github.com/ryangerardwilson

## What I Am Optimizing For Now

I want to become unusually good at a narrow but durable combination:

- terminal-native product design
- agentic software and AI workflows
- model-backed operational systems
- opinionated interfaces with real taste

I care less about looking modern than about building things that feel authored,
fast, and exact.

I also spend a lot of time relearning math and physics from the intuition up,
because I do not trust shallow understanding and I do not want AI to turn my
brain into paste.