Skip to content

NACHOSAG

// SOFTWARE ENGINEER

I build software. Web apps, APIs, distributed systems — full stack when it makes sense, deep backend when the problem needs it. I care about architecture and testing, but mostly I care about shipping things that actually work.

system_status.sh
os: Ubuntu 24.04 LTS
shell: bash
languages: [ "TypeScript", "Python" ]
location: Buenos Aires, AR
$ fetch --profile developer_identity
> READY_TO_INITIALIZE...
>
// ABOUT

CORE_MINDSET

I like understanding how things work under the hood. Not just wiring libraries together and calling it a day. Architecture, data modeling, clean code — those come before typing. If you don't understand why, the implementation doesn't matter.

I've built a lot of stuff — from REST APIs to Cloudflare Workers at the edge, from graph algorithm solvers to full-serverless platforms. I work in Python, TypeScript, Java, and Go. I've done frontend with React and Angular. I just like building things that work well.

The best compliment I get is when someone says my code is easy to work with. Clear architecture, good tests, no surprises. That's what good engineering looks like to me — code you can pick up months later and understand immediately.

// SYST_ARCH

SCALABLE_CORE

I build systems that don't collapse when they grow. Clean architecture with real separation of concerns — controllers, services, repositories. Serverless when it makes sense, distributed when the problem needs it.

// PERF_OPT

LATENCY_CONTROL

I care about performance, but not prematurely. Async I/O end-to-end when it matters, optimized algorithms when brute force won't cut it. And yeah, I know what's happening at the hardware level too.

// CODE_QUAL

ROBUST_LOGIC

I actually test my code. Unit, integration, stress — whatever the project needs. I write tests because I've been burned by untested code at 3 AM, and I don't want to go back.

// MENTOR_X

TECH_LEADERSHIP

I've mentored devs who were just starting out and helped teams level up their architecture game. Good code is good code — I just help people find their way there.

// REPOSITORY_INDEX

PROJECT_EXPLORER

folder sigrh
backend
algorithms
algorithms
games
backend
academic
serverless
folder async-api
backend
cli
folder notes-app
fullstack
folder auth-flow
backend
// CAPABILITY_MATRIX

TECH_STACK

LANGUAGES

TypeScript Python Java Go JavaScript

FRONTEND

React Angular Zustand Vite Vanilla CSS

BACKEND

FastAPI Express Nest SQLModel SQLAlchemy Cloudflare Workers

INFRA

Docker Docker Compose Cloudflare Pages Wrangler CLI GitHub Actions

DATA

PostgreSQL MySQL SQLite MongoDB Cassandra Redis Cloudflare D1 / R2

PIPELINE

Git GitHub Actions Pytest Vitest Playwright oxlint
pipeline_schema.ascii
GENTLE-AI SDD PIPELINE
EXPLORE Understand the problem before solving it
PROPOSE Define what we're building and why
SPEC Write down what success looks like
DESIGN Plan the architecture before writing code
TASKS Split the work into digestible pieces
APPLY Build it, step by step, testing as you go
VERIFY Prove it actually works
ARCHIVE Ship it, document it, move on
QUALITY GATES: TDD · Fresh Reviews · Judgment Day
// DEVELOPMENT_METHODOLOGY

ENGINEERING_LIFECYCLE

01. REQUIREMENT_ANALYSIS

Before I write code, I figure out what the problem actually is. Clear requirements and defined success criteria save months of rewrites. It's that simple.

02. ARCHITECTURAL_BLUEPRINT

I design systems that make sense. Separation of concerns, dependency injection, testable by design. The goal is code that doesn't become a nightmare six months in.

03. ITERATIVE_DEVELOPMENT

The SDD pipeline — explore → propose → spec → design → tasks → apply → verify → archive. Each step catches mistakes early so you don't pay for them later. No skipping, no shortcuts.

04. QUALITY_ASSURANCE

I test as I go. TDD when the stack supports it, reviews that actually catch things, and a final adversarial pass that doesn't let anything slip through. No rubber-stamp approvals.

// TRANSMISSION_READY

ESTABLISH CONNECTION

I'm always open to interesting problems and good teams. Remote, on-site, doesn't matter — if you're building something worth solving, let's talk.