A few things that define how I work:

• 🧭 Troubleshooting-first mindset — even in unfamiliar systems
• ⚙️ Intentional laziness (the good kind) — if it’s repetitive, it gets automated
• 🧠 Fast, self-directed learner (I’ve been called a sponge)
• 🚀 Ambitious, with a long-term mindset

Lazy by design. Curious by default. Very ambitious.

• Production stability and user impact come first
• Mitigate fast, stabilize the system, then investigate
• Prefer safe, reversible patches over perfect fixes under pressure
• Take the time afterwards to understand root causes and fix things properly

A self-hosted homelab used to run, automate, and experiment with real-world services.

Why it exists I wanted a controlled environment to run production-like workloads at home — not demos, but systems that actually need to stay up, survive failures, and be maintained over time.

What I focused on

• Operating and evolving a living system, not just deploying it once
• Automating repetitive operational tasks
• Troubleshooting failures across infrastructure, networking, and services
• Making safe changes with minimal downtime

Tech & themes Infrastructure · Automation · Reliability · Self-hosting · Systems

[Organization → https://github.com/feenx-lab]

An open-core personal finance app focused on clarity, automation, and long-term planning.

Why it exists I was tired of spreadsheets and tools that require constant manual upkeep. SimpleSave treats budgeting as a system — something that should work for you, not demand attention.

What I focused on

• Reducing user friction through automation
• Designing workflows that handle partial failures gracefully
• Integrating with external APIs safely
• Iterating quickly while keeping production stability in mind

Tech & themes Ruby · APIs · Automation · Reliability · Product Thinking · Learning

[Organization → https://github.com/simplesave-app]

A lightweight HTTP proxy that retries failed requests for automation-heavy media services.

Why it exists Some services in my homelab stack were brittle when external requests failed. I wanted a simple, targeted way to improve reliability without modifying upstream apps.

What I focused on

• Quick mitigation of real production pain points
• Designing a small, composable tool that does one thing well
• Improving system reliability without overengineering

Tech & themes HTTP · Tooling · Reliability · Pragmatic Engineering

[Repository → https://github.com/azunaVT/retryrr]

I enjoy systems in all their forms, even outside of code:

• 🎮 Gaming & streaming — automation, progression, and long-form problem solving
• 🏆 Achievement hunting — optimizing paths, mastering mechanics, and finishing what I start
• 🛡 CTFs & security challenges — learning by breaking assumptions
• 🧙 World & story building — DnD, game dev, and narrative systems
• 🎲 Board games — strategy, cooperation, and emergent decision-making
• 🎧 Music (especially lo‑fi) — always on in the background; focus, flow, and atmosphere