Sobre mí

Hola, soy Yorch.

Deyvidyorch Sánchez

En papeles Deyvidyorch Sánchez, pero Yorch está bien. Soy Frontend Developer (React & TypeScript) desde Lima, Perú. Llevo ~2.5 años en frontend y ~4.5 en tecnología: empecé en infraestructura cloud y terminé enganchado con construir interfaces.

Ahora trabajo en un producto educativo con ~1.000 usuarios: dirigí la migración de su frontend (~50k líneas) a una arquitectura modular por features, definí la API y los contratos de su design system de ~50 componentes, y hago las interfaces para 4 roles de usuario, con todo en español e inglés.

Creo que la mejor arquitectura es la que el equipo entiende sin que se lo expliquen dos veces. Por eso prefiero documentar decisiones (ADRs), convenciones explícitas y código aburrido sobre clever code.

01 / Experiencia

Donde trabajé

  1. Dic 2024 — Presente

    Frontend Full Stack Developer

    El Sol Neighborhood Educational Center · Remoto

    • Desarrollo CHW Learning Hub, plataforma educativa para Community Health Workers con ~1.000 usuarios y cuatro perfiles de acceso, en un equipo de 7 personas.
    • Definí la API y los contratos del design system (~50 componentes): props, variantes, estado controlado desde el exterior e integración con React Hook Form e i18n. Con esos componentes y las tablas en TanStack Table v8 reutilizadas en +15 pantallas, desarrollar una funcionalidad nueva pasó a ser ensamblar piezas existentes.
    • Dirigí la migración de un frontend React + TypeScript de ~50k líneas desde una base legacy a una arquitectura modular por features con separación de capas (services → formatters → hooks → UI), sin interrumpir producción: un cambio de feature quedó contenido en una sola carpeta.
    • Escribí las instrucciones de repositorio para los agentes de IA del proyecto: contexto, convenciones y límites.
    • Reviso los cambios generados con asistencia de IA antes de integrarlos: controlo qué archivos se modifican y por qué, descarto los que exceden el alcance de la tarea y reutilizo los componentes existentes en lugar de duplicarlos.
    • Implementé autenticación con JWT y cookies HttpOnly e integré APIs REST.
  2. Nov — Dic 2024

    Frontend Developer

    Nolatech AI · Remoto

    • Refactoricé componentes y corregí bugs en el frontend de una aplicación de loterías (React + Tailwind CSS).
  3. Ene — Ago 2024

    Frontend Developer

    Distral SRL · Lima, Perú

    • Desarrollé sistemas web tipo CRUD y paneles de administración responsivos en React + Tailwind CSS, con formularios validados y tablas con filtros, orden y paginación.
    • Implementé autenticación y persistencia con Firebase (Auth, Firestore, Storage) e integré APIs externas como Google Maps.
  4. Ago — Dic 2023

    Analista Cloud

    Distral SRL · Lima, Perú

    • Participé en la migración a la nube de robots RPA (Automation Anywhere) de un cliente bancario y automaticé despliegues y reportes con scripts.
  5. Ene 2022 — Jun 2023

    Analista de Sistemas / Cloud

    Bit Perfect Solutions · Lima, Perú

    • Administré servicios en Huawei Cloud, AWS y Google Cloud (WAF, ECS, VPN, backups) y diseñé diagramas de arquitectura para despliegues en la nube.
  6. Título · Jun 2025

    Ingeniero de Software — Título Profesional

    Universidad Peruana de Ciencias Aplicadas (UPC) · Lima, Perú

    • Migré el frontend (Razor → React + Vite) del sistema interno de generación de reportes para la acreditación internacional de las carreras de la facultad.

02 / Cómo trabajo

Dirigiendo agentes de IA

Buena parte de lo que entrego hoy lo escribe un agente. Mi trabajo es decidir qué se construye, fijar cómo se sabe que está bien, y rechazar lo que no cumple.

  1. 01

    Escribo las reglas antes que el prompt

    Cada repo lleva sus instrucciones para los agentes: contexto del proyecto, convenciones y límites explícitos de lo que no deben tocar. Es la parte que más cambia el resultado y la que casi nadie escribe.

  2. 02

    Especifico contratos, no tareas

    Props, variantes, estado controlado desde el exterior, integración obligatoria con React Hook Form e i18n. Los criterios de aceptación se fijan antes de pedir nada; sin ellos no hay forma de decir si la salida sirve.

  3. 03

    Reviso el radio de impacto

    Antes de integrar miro qué archivos se modificaron y por qué. Lo que excede el alcance de la tarea se descarta, aunque funcione: un cambio que toca treinta archivos para resolver uno es deuda, no ayuda.

  4. 04

    Reutilizar gana a generar

    Si ya existe la abstracción, la salida correcta es usarla. Conocer el propio codebase es lo que evita que un design system se fragmente en variantes casi iguales.

Un caso concreto

Pedí un cambio en los filtros de una tabla. Volvieron ~30 archivos con una línea cada uno «robusteciendo» componentes que ya funcionaban, más componentes nuevos para algo que ya existía en el design system. Lo rechacé por dos razones: el radio de impacto no correspondía a la tarea, y creaba variantes duplicadas de piezas que ya aceptaban React Hook Form e i18n. Se consolidó en un hook reutilizando lo que había.

03 / Principios

Tres cosas que creo

  1. 01

    Medir antes de optimizar

    Sin profiling, cualquier optimización es decoración. Los cuellos de botella reales casi nunca son donde uno cree.

  2. 02

    Documentar decisiones, no código

    El código bien nombrado se explica solo. Lo que necesita texto es por qué elegí esta opción y no las otras.

  3. 03

    Aburrido > clever

    Un equipo que entiende el código a las 3am es más rápido que uno que necesita arqueología para cada bug.

Si buscas a alguien que construya interfaces con criterio y cuide los detalles — hablemos.

Frontend o Full Stack, mid / semi-senior. Remoto (o Lima, presencial), UTC−5 · solapamiento completo con husos de EE.UU.. Contractor con RUC y recibo por honorarios, o planilla. Cómodo en equipos asíncronos y orientados a resultados.