I'm a software engineer in Lacey, Washington. For three years I built React and TypeScript applications end to end for two small companies — the storefronts customers bought from, and the internal dashboards the people running those companies made decisions in. The second half of that work is the part that stuck with me.
A dashboard is only as honest as the schema underneath it. So the projects I've built since have started further down: designing the relational model, writing the ETL that fills it, keeping imports idempotent and their failures auditable, then exposing the whole thing through an API with filters composable enough that the map, the charts and the table can never disagree.
Right now I'm aiming at data and AI platform work — the systems that make information trustworthy before anyone builds on top of it. Outside that: guitar, which is how ChordLab happened, and Tokyo's rail network, which is how the other two did.
- Correctness at the boundary
- Constraints belong in the database, not in a comment. Natural keys, restricted deletes and indexes matched to the query paths that actually run.
- Failures you can read
- A rejected row keeps its raw line and every reason it failed. An import that half-worked should be obvious, re-runnable and auditable.
- One filter, every panel
- Interfaces are where the data model gets judged. If a filter changes the map but not the chart, the model leaked.
- Tests on the invariants
- Integration tests against real migrations, contract tests in CI. Cover what breaks silently, not what breaks loudly.
