How I think about engineering
I don't build features — I build systems. The distinction matters. A feature lives until the next sprint. A system lives for years and keeps working long after its author has moved on.
That means: before writing code, I ask uncomfortable questions. Why this approach? What happens at 10× load? Who maintains this in three years? Good design decisions early are cheaper than production refactors.
What I do
For over five years I've been building backend systems in PHP and Laravel — from APIs for mobile apps to high-load web services.
Currently at one.pix, I focus on backend development and API architecture. My work spans complex business logic, queues, integrations (including Netsuite), Docker environments, CI/CD, and Linux server administration.
I specialize in:
- Backend Architecture — REST API design, complex business logic, integrations
- Performance — query optimization, caching, queue design, legacy code refactoring
- Infrastructure — Docker, CI/CD, Nginx, AWS, Linux
- Frontend — occasionally closing tasks on Vue.js
How I approach problems
Understand first, code second. Most technical problems are actually problems with domain understanding or requirements. I invest time in getting to the root of things rather than jumping to solutions.
I prefer boring, predictable code over clever code. Clever code is technical debt with a deferred payment. A simple solution that's easy to read, debug, and extend is almost always the right choice.
Tests are not optional. Code without tests is code you can't trust. I write tests not as a formality, but to have confidence when making changes.
What motivates me
Hard problems with high correctness requirements. Systems where mistakes are expensive — payment processing, logistics, financial calculations. There's no room for "should work" — only for "works."
I enjoy working in teams where code review is knowledge exchange, not a checkbox. Where a junior can ask "why?" and get a real answer.