01 / work
Work
Four years of product engineering. The domains are named. The employers are not.
The last four years
Software engineer
Product systems where the domain is stubborn and the interface has to stay honest. Healthcare and electronic records have been a large part of that: sensitive data, workflows older than the software, and boundaries where a sloppy model becomes a real mistake.
The daily material around it is familiar and not glamorous. Dense frontends. HTTP APIs. Realtime when a page actually needs to move. Authentication and permission. Billing and other stateful side effects. Interoperability between systems that were not designed to speak. Compliance-oriented engineering, which mostly means knowing what you are not allowed to be casual about.
Left off this page
Names, numbers, clients
Employers, clients, and metrics stay off this site. The work is real. The branding, and anything confidential, is not mine to turn into a portfolio graphic.
What the work is
- 01
Domain models
Types and boundaries for data that does not fit a tutorial. In a regulated vocabulary, the model is the product.
- 02
Interfaces
Frontends that stay understandable when the data is incomplete, duplicated, or late. Density without a junk drawer.
- 03
Boundaries
APIs and integration edges. What may cross, what may fail, and who owns the retry.
- 04
Identity and money
Authentication, permissions, and billing. State with consequences, so the boring path has to be the correct one.
- 05
Realtime
Only where a live view earns the complexity. A socket is not an architecture.
- 06
Under the framework
When the docs stop, read the mechanism. That habit is also why the lab exists.
How I like to work
Design first. I want the shape — boundaries, data flow, failure — before an agent or a framework starts typing.
AI is part of how I implement now. It is useful, and it is easy to let it steer. I would rather own the design and spend the speed on the parts that should be fast.