Over roughly a decade, I have moved between hands-on engineering, architecture, infrastructure, technical leadership, recruitment, mentoring, cross-functional execution, and solo product building.
The common thread is simple: understand the real constraint, become useful quickly, and take ownership beyond the obvious boundary of the job.
I joined my longest-running product company as a junior backend engineer. Nearly eight years later, the role had expanded into engineering and technical leadership.
Backend work became architecture. Architecture became distributed processing, cloud infrastructure, deployment, reliability, cost, production debugging, and the connective tissue between systems.
I worked on TB-scale geospatial workloads, asynchronous and real-time pipelines, 20+ internal and external systems and integrations, and a production AWS → GCP migration completed in roughly four weeks without service interruption.
I stayed hands-on while taking on technical planning, delivery coordination, QA and release discipline, infrastructure continuity, and cross-functional decisions spanning backend, frontend, design, product, QA, and AI/ML research.
Eventually I was leading or coordinating work across more than 20 people in different disciplines.
My work also expanded into recruitment and hiring: technical interviews, test design, probation reviews, performance feedback, and mentoring engineers.
That changed my view of leadership. Good technical decisions are rarely separated from the people, incentives, communication, and context around them.
Different engagements repeatedly forced me to switch domains, stacks, team shapes, and levels of ownership without waiting for the environment to resemble the last one.
Full product delivery across IoT, scheduling, backend, frontend, Android, Docker, cloud, and on-premise deployment.
Main backend engineer on a WordPress → Rails rebuild covering production data, auth, access, internal workflows, integrations, and launch.
Took over an existing production Rails backend after the previous backend engineer left, then contributed to a full Python/FastAPI rewrite while handling substantial DevOps work.
Built a Next.js mini SaaS as the sole full-stack engineer after a previous engineering relationship turned into a second collaboration.
Entered an existing Rails product, resolved a Klarna integration issue, fixed broken endpoints, and helped unblock work the team was stuck on.
I often go deeper into unfamiliar systems when I need to understand them. That has taken me beyond software into networking, homelab infrastructure, structural analysis, home systems, automation, and other areas where the interesting part is how assumptions, constraints, and failures interact.
I am not trying to become a specialist in every discipline. I like understanding how complex systems are modeled, where decisions propagate, and what another engineering field can teach me about my own.
I build apps, scripts, and developer tools for friction I encounter in work and daily life. Using them myself keeps the feedback immediate and the next improvement grounded in a real need.
I kept restarting my machine and manually rediscovering local servers, workers, scripts, and supporting services.
I did not want every project to become an OS service or a container. So I built the local control plane I wanted: process supervision, dependencies, health checks, logs, runtime state, ownership recovery, REST/SSE, tests, and standalone releases.
View stakl on GitHub ↗A practical, artifact-driven approach to long-running AI-assisted engineering: exploration, plans, RFCs, ADRs, task decomposition, review, and durable context.
Open the repository ↗A tool for choosing an appropriate AI model for a specific task instead of defaulting to the same model for everything.
A pre-MEP and homeowner planning tool for organizing services, resources, requirements, and early planning decisions.
A focused application for designing network layouts.
The interesting problem is not generating more code. It is keeping humans and agents aligned across long-running work without losing requirements, architecture, edge cases, review context, or decisions.
I now use this style of workflow across public and private products and in current contract work with a two-engineer team.
“The tools changed, so I changed how I work instead of defending the old process.”
I can go deep in the code, widen the lens to the whole system, and switch between those modes when the situation changes. A few principles have stayed consistent.
Follow the work through implementation and production, then learn from how it behaves in the real system.
Choose designs that solve the problem without making the next engineer pay unnecessary complexity tax.
Monitoring, failure, recovery, cost, and handover belong in architecture decisions, not after them.
Go deep enough into unfamiliar problems to test assumptions and carry useful lessons into the next system.
I am interested in ambitious products, difficult technical problems, strong teams, and environments where ownership matters. That could mean hands-on engineering, staff/principal-level work, engineering leadership, product building, founder collaboration, or a focused technical challenge.