$ cat about_me.md
# how I build, learn, and make engineering decisions
I build software to remove operational friction from real workflows. My current direction is Rust-first backend engineering, with a particular interest in security-conscious systems, education platforms, and AI automation that can be validated and operated.
I started independent software work in 2023. In 2025, I started IPE-24 Classroom after seeing how fragmented chats, resource links, and routine updates slowed down my university batch.
That first product taught me the difference between a feature that works once and a system that people can depend on: clear ownership, fast feedback, deployment discipline, and an escape path when reality does not match the happy path.
My work has moved from product surfaces into the boundaries beneath them: tenant isolation, authenticated identity, auditability, typed contracts, offline synchronization, and tests for what a caller must not be allowed to do.
Vendryx contributes database-level multi-tenant isolation with PostgreSQL FORCE RLS. Hall Security adds an observe-only Rust research system with authenticated event transport and a durable outbox. LogBook Institution adds Go authorization tests and explicit tenant identity boundaries. These are distinct examples of implemented techniques, not claims that all three are production-ready.
These repositories remain private. Recent CI failures and incomplete deployment qualification are reflected in the relevant case studies rather than hidden behind finished-product labels.
I learn fastest when a concept is attached to a real constraint. I read the relevant documentation, inspect the system boundary, build a small verifiable slice, and use tests and failures to refine the model.
- Define: name the user, workflow, invariant, and unacceptable failure.
- Build: implement the narrowest useful path with explicit contracts.
- Verify: test happy paths, negative capabilities, integration boundaries, and operational recovery.
- Document: record trade-offs, current status, and what still blocks release.
I am most interested in backend roles and collaborations where the work involves reliable systems rather than isolated demos: security-sensitive services, education infrastructure, operational automation, developer tools, and AI features that need structure around them.
I bring early-stage ownership, product curiosity, and a willingness to learn the missing domain deeply. I am also careful about scope: a prototype is a prototype, a private repository is private, and a claim should be backed by an artifact or a measured result.