Juan RamírezAprendizajeEN

Full Stack Developer que construye con IA

Productos completos: frontend, backend, datos, pagos y el pipeline que los lleva a producción.

Juan Ramírez

01Skill2 casos

Dinero real, tarjetas reales, celulares sin señal: flujos que aguantan.

  • Katapult Labs
  • Devsu
01.1 — Katapult LabsSenior Full Stack Developer · 2025 — Hoy
  • Frontend
  • Móvil
  • Backend
  • Base de datos
  • Integraciones
  • CI/CD
  • IA

Una plataforma de transacciones sobre Stripe: checkout, tarjetas guardadas, suscripciones, comisiones, payouts y recibos. Un solo flujo, construido y mantenido por mí.

IA en el procesoTests, debugging y UI al píxel, acelerados con IA.

Next.js / NestJS / Stripe / Supabase Postgres / Redis / Design system

revisaintenteventospersisteCheckoutStripe ElementsAPI NestJScommands · queriesGuard antiabusoRedis · por dispositivoStripeintents · suscripcionesCuentas conectadascomisiones · payoutsWebhooksfirma verificadaPostgresestado · RPCRecibosPDF · CSV · S3
01 / 08
  1. Los compradores pagan dentro del producto con Stripe Elements.
  2. Una API en NestJS crea y confirma cada PaymentIntent.
  3. Antes de cobrar una tarjeta, un guard en Redis revisa el dispositivo.
  4. Stripe maneja tarjetas, métodos guardados y suscripciones.
  5. Las cuentas conectadas reciben su parte; la plataforma se queda con su comisión.
  6. Webhooks firmados reportan lo que de verdad pasó.
  7. Cada estado de la transacción queda en Postgres.
  8. Los recibos y las exportaciones salen de ese único registro.
Fig. 01.1.1 — Checkout, un cobro protegido, webhooks firmados y un único registro persistido.

Construido

  1. 01Auth
  2. 02Usuarios
  3. 03Checkout
  4. 04Suscripciones
  5. 05Webhooks
  6. 06Payouts
  7. 07Recibos
  8. 08Reportes
Fig. 01.1.2 Pipeline de entrega: cada merge recorre el mismo camino a producción.

Impacto

$100K+

En transacciones, cientos de miles de dólares

100%

Del flujo de pagos construido y mantenido por mí

01.2 — DevsuMobile & Frontend Developer · 2024 — 2025
  • Frontend
  • Móvil
  • Backend
  • Base de datos
  • Integraciones
  • CI/CD
  • IA

Pagos móviles para la billetera digital más grande de Ecuador: códigos QR, deep links y pagos sin conexión cifrados en el dispositivo.

React Native / NestJS / TypeScript / AWS / Design system

sin señalApp billeteraReact NativeQR · deep linkiniciar un pagoPago sin conexióncifrado en el equipoVuelve la redsincronizaServicios backendNestJS · AWSCachésin respuestas vacíasGráficasel dinero, visual
01 / 07
  1. Una app de billetera, muchas veces con mala señal.
  2. Se paga escaneando un QR o abriendo un deep link.
  3. Sin señal, el pago se cifra y se guarda en el dispositivo.
  4. Cuando vuelve la red, se sincroniza.
  5. Los servicios backend toman el control, con un equipo grande y distribuido.
  6. Una capa de caché evita que respuestas vacías o inválidas lleguen al usuario.
  7. Gráficas interactivas le muestran a la gente a dónde va su dinero.
Fig. 01.2.1 — Un pago que empieza sin conexión y se liquida cuando vuelve la red.

Construido

  1. 01Pagos QR
  2. 02Deep links
  3. 03Modo offline
  4. 04Cifrado
  5. 05Gráficas
  6. 06Migración de servicios
Fig. 01.2.2 Pipeline de entrega: cada merge recorre el mismo camino a producción.

Impacto

1000s

De personas pagando sin conexión

#1

Billetera digital de Ecuador

02Skill3 casos

Los agentes escriben. La arquitectura, la revisión y el resultado son míos.

  • Cada proyecto
  • Neura
  • Lucka · Lexio
02.1 — Cada proyectoFlujo aumentado con IA · 2025 — Hoy
  • Frontend
  • Móvil
  • Backend
  • Base de datos
  • Integraciones
  • CI/CD
  • IA

No confío en que la IA escriba buen código. Así que construí un sistema que no necesita confianza.

Claude Code / MCP / Agents / Skills / Hooks

plancada cambioNotas de reuniónGranolaTicketsescritos por ClaudeAgente plannerdecisiones → preguntasClaude Codereglas · Figma · códigoHooksbloquear · lint · formatoPlanner de testsJest · CypressRevisión con IA4 revisores + refutadorPull requestpreview en vivo
01 / 08
  1. Empieza en una reunión. Granola toma las notas.
  2. Claude las convierte en tickets.
  3. Un agente planner escribe el plan. Cada decisión se vuelve una pregunta que yo respondo.
  4. Claude programa con un archivo de reglas corto y estricto, y el diseño de Figma.
  5. Los hooks revisan cada cambio. Color quemado, nombre de archivo mal, push a main: bloqueado.
  6. Un planner de tests propone los casos borde. Yo elijo. Jest y Cypress los corren.
  7. Cuatro revisores con IA revisan el código en paralelo. Un quinto intenta demostrar que se equivocan.
  8. Cada pull request sale con un preview en vivo.
Fig. 02.1.1 — De una reunión a un pull request revisado, con agentes escribiendo el código.

El ciclo

  1. 01Notas
  2. 02Ticket
  3. 03Plan
  4. 04Código
  5. 05Hooks
  6. 06Tests
  7. 07Revisión IA
  8. 08PR
Fig. 02.1.2 Pipeline de entrega: cada merge recorre el mismo camino a producción.

Impacto

+200%

Más entregas desde que la IA entró al ciclo

3 días

Para construir una aplicación completa

2 sem

Para lanzar una funcionalidad estimada en tres meses

02.2 — NeuraTech Lead · Full Stack (medio tiempo) · 2025
  • Frontend
  • Móvil
  • Backend
  • Base de datos
  • Integraciones
  • CI/CD
  • IA

Neura, un asistente personal con IA construido desde cero: mandas una nota de voz y se escriben correos y se crean tareas. Web, móvil y backend, con un equipo de tres.

IA en el procesoIA dentro del producto y en toda la construcción: pantallas, integración con la API e iteración de UI.

Next.js / React Native / Express / Supabase / Redis / OpenAI / Design system

transcripciónNota de vozapp móvilAPI backendExpress · authTranscripciónvoz → textoIntención (IA)qué hacer despuésCorreoescrito y enviadoTareascreadas y agendadasApp webrevisa todo
01 / 07
  1. La persona solo habla: una nota de voz desde el celular.
  2. Un backend la recibe, con autenticación y límites de uso.
  3. El audio se vuelve texto.
  4. Un paso con IA decide qué se pidió.
  5. Los correos se escriben y se envían.
  6. Las tareas se crean.
  7. Una app web muestra todo lo que hizo Neura.
Fig. 02.2.1 — Entra una nota de voz, salen correos y tareas.

Entrega

  1. 01Idea
  2. 02Alcance
  3. 03Diseño
  4. 04Desarrollo
  5. 05Integración
  6. 06Lanzamiento
Fig. 02.2.2 Pipeline de entrega: cada merge recorre el mismo camino a producción.

Impacto

15+

Pantallas entregadas

<3

Meses de la idea a una app funcionando

3

Apps: web, móvil y backend

02.3 — Lucka · LexioProyectos propios · 2026
  • Frontend
  • Móvil
  • Backend
  • Base de datos
  • Integraciones
  • CI/CD
  • IA

En Lucka y Lexio, la IA escribe datos que la app guarda: gastos desde una nota de voz, lecciones desde una frase. Un esquema, cualquier proveedor, nada se guarda sin validar.

Tauri / Rust / SQLite / whisper.cpp / llama.cpp

textorespuestaconfirmadoVoz o textolo que da el usuarioWhisperen el equipoUn esquema JSONsalida estructuradaModelo localQwen · llama.cppTu propia keyOpenAI · Claude · GeminiValidacióntipada · testeadaSQLitea través de Rust
01 / 07
  1. El usuario habla o pega un texto.
  2. La voz se vuelve texto en la misma máquina.
  3. Un esquema JSON le dice a cada modelo exactamente qué devolver.
  4. Puede responder un modelo local, con una gramática que no puede romper.
  5. O OpenAI, Anthropic o Gemini, con la key del propio usuario.
  6. Cada respuesta se valida y se convierte en registros reales con código testeado.
  7. Solo entonces se guarda, después de que el usuario confirma.
Fig. 02.3.1 — Respuestas de un modelo en las que no se puede confiar, convertidas en filas confiables.

Flujo

  1. 01Hablar
  2. 02Transcribir
  3. 03Interpretar
  4. 04Validar
  5. 05Confirmar
  6. 06Guardar
Fig. 02.3.2 Pipeline de entrega: cada merge recorre el mismo camino a producción.

Impacto

4

Proveedores de IA detrás de una sola interfaz

1

Esquema que llena cada proveedor

0

Respuestas del modelo guardadas sin validar

03Skill2 casos

APIs que atienden a cientos de personas a la vez, sobre SQL, NoSQL y Redis.

  • Katapult Labs · Kuepa · GooDev
  • Kuepa → Katapult Labs
03.1 — Katapult Labs · Kuepa · GooDevFull Stack Developer · 2022 — Hoy
  • Frontend
  • Móvil
  • Backend
  • Base de datos
  • Integraciones
  • CI/CD
  • IA

APIs que responden a cientos de personas al mismo tiempo: datos relacionales y no relacionales, webhooks de proveedores de pago, y Redis delante de lo que se pone lento.

IA en el procesoPlanes de implementación, código backend y tests hechos con IA, revisados línea por línea.

NestJS / Express / PostgreSQL / MySQL / MongoDB / Prisma / TypeORM / Sequelize / Mongoose / Redis

eventosleeescribesi no estáCientos de usuariosal mismo tiempoAPINestJS · ExpressWebhooksfirma verificadaCaché Redisresponde desde memoriaPrisma · TypeORMSequelize · MongooseRelacionalPostgres · MySQLNo relacionalMongoDB
01 / 07
  1. Cientos de personas a la vez, cada una pidiendo sus propios datos.
  2. Una API les responde a todas, con autenticación, roles y límites de uso delante.
  3. Proveedores como Stripe mandan eventos por webhook; cada uno se verifica antes de contar.
  4. Redis responde desde memoria las lecturas frecuentes, para no preguntarle dos veces a la base de datos.
  5. Las escrituras pasan por un ORM: Prisma, TypeORM, Sequelize o Mongoose, o SQL puro, lo que pida el proyecto.
  6. Los datos con relaciones estrictas viven en Postgres o MySQL.
  7. Los documentos que cambian de forma viven en MongoDB.
Fig. 03.1.1 — Muchos usuarios a la vez, una API, una caché delante y la base de datos correcta detrás.

Construido

  1. 01Auth y roles
  2. 02APIs REST
  3. 03SQL
  4. 04NoSQL
  5. 05ORMs
  6. 06Webhooks
  7. 07Caché Redis
  8. 08Jobs
Fig. 03.1.2 Pipeline de entrega: cada merge recorre el mismo camino a producción.

Impacto

100s

De usuarios al mismo tiempo, cada uno con sus propios datos

SQL + NoSQL

Postgres, MySQL y MongoDB, según lo que necesiten los datos

Webhooks

Eventos de pago, verificados antes de guardar nada

03.2 — Kuepa → Katapult LabsFull Stack Developer · 2022 — Hoy
  • Frontend
  • Móvil
  • Backend
  • Base de datos
  • Integraciones
  • CI/CD
  • IA

Primero, para que una plataforma edtech respondiera más rápido. Después, para limitar el uso de una API y frenar el card testing antes de que se cobre una tarjeta robada.

Redis / Node / NestJS / Lua / Stripe

permitidorechazadose disparaSolicitud de pagocon id de dispositivoBucket equipo · IPquién preguntaControl de ritmointents por 10 minStripeintento de cobroWebhook de rechazohuella de tarjetaContadores Redisscripts Lua atómicosCircuit breakerbloqueo · retry-after
01 / 07
  1. Cada solicitud de pago lleva un id de dispositivo.
  2. Cada una se agrupa por dispositivo y por IP.
  3. Demasiados intentos de pago desde un dispositivo en diez minutos: bloqueado en el acto.
  4. Si no, Stripe intenta cobrar la tarjeta.
  5. Los rechazos vuelven por webhook, con la huella de la tarjeta.
  6. Redis cuenta las tarjetas rechazadas distintas por bucket, de forma atómica.
  7. Tres tarjetas malas en un dispositivo disparan el breaker. Mucha gente en el mismo Wi-Fi, nunca.
Fig. 03.2.1 — Un circuit breaker de dos capas que cuenta rechazos, no tráfico.

Con los años

  1. 01Caché de respuestas
  2. 02Rate limiting
  3. 03Storage del throttler
  4. 04Tope de ritmo
  5. 05Breaker de card testing
Fig. 03.2.2 Pipeline de entrega: cada merge recorre el mismo camino a producción.

Impacto

Más rápido

Lecturas frecuentes servidas desde memoria y no desde la base de datos

Uso justo

Límites compartidos por todos los servidores, para que nadie sature la API

Fraude

Tarjetas robadas bloqueadas antes de cobrarse

04Skill1 caso

Cada regla se revisa tres veces antes de que algo llegue a producción.

  • Katapult Labs · Lucka
04.1 — Katapult Labs · LuckaFull Stack Developer · 2025 — Hoy
  • Frontend
  • Móvil
  • Backend
  • Base de datos
  • Integraciones
  • CI/CD
  • IA

Cada regla corre cuando el agente escribe, cuando hago commit y cuando CI hace merge. Las apps de escritorio van más allá: se lanzan builds reales de macOS y Windows antes de cada release.

IA en el procesoLas mismas reglas cuidan a humanos y agentes. Ninguno se las puede saltar.

GitHub Actions / Husky / Jest / Cypress / Supabase CLI / Vercel

deploypromueveAl escribirhooks de ClaudeAl hacer commitHusky · lint-stagedAl hacer mergelint · tipos · JestMigracionessobre una DB limpiaPreviewVercel, por PRCypresscontra el previewAmbientes3, una base cada uno
01 / 07
  1. Al escribir: los hooks de Claude bloquean lo que las reglas prohíben y pasan lint a cada cambio.
  2. Al hacer commit: Husky y lint-staged vuelven a correr las mismas reglas.
  3. Al hacer merge: CI corre lint, tipos y tests unitarios.
  4. Cada migración se aplica sobre una base de datos local limpia antes de poder salir.
  5. Cada pull request tiene su propio preview en Vercel.
  6. Cypress prueba el preview real en un navegador.
  7. Las migraciones avanzan un ambiente a la vez: feedback, staging, main.
Fig. 04.1.1 — Tres capas de control, un preview por pull request y migraciones por ambiente.

Entrega

  1. 01Escribir
  2. 02Commit
  3. 03CI
  4. 04Migraciones
  5. 05Preview
  6. 06Cypress
  7. 07Staging
  8. 08Producción
Fig. 04.1.2 Pipeline de entrega: cada merge recorre el mismo camino a producción.

Impacto

Checkout

Pagos únicos y recurrentes, probados de punta a punta en un navegador real en cada PR

Roles

Quién puede ver y hacer qué, revisado con tests unitarios en cada PR

Migraciones

Cada cambio de base de datos aplicado a una base limpia antes de salir

05Skill1 caso

Despliegues más pequeños, una factura más pequeña, equipos que publican solos.

  • Kuepa Edutech
05.1 — Kuepa EdutechFull Stack Developer · 2022 — 2024
  • Frontend
  • Móvil
  • Backend
  • Base de datos
  • Integraciones
  • CI/CD
  • IA

Propuse y construí una arquitectura con Module Federation para una plataforma educativa, y la mantuve rápida: tiempo real, jobs, limpieza de legacy y tests unitarios.

React / Module Federation / Node / Socket.io / AWS / Design system

manifesten vivoUsuariosestudiantes · asesoresApp shellhost · rutasAWSremoteEntry.jsDashboardsremoteLeads y reportesremotePagosremoteAPI NodeSocket.io · jobs
01 / 07
  1. Estudiantes y asesores, una sola entrada.
  2. Un shell liviano maneja las rutas y carga el resto.
  3. Los remotes se descargan en tiempo de ejecución desde AWS.
  4. Los dashboards se despliegan solos.
  5. Leads y reportes se despliegan solos.
  6. Pagos se despliega solo.
  7. Un backend en Node envía actualizaciones en vivo por Socket.io y corre los jobs.
Fig. 05.1.1 — Un shell liviano que carga remotes desplegados por separado, con un backend en vivo detrás.

Construido

  1. 01Propuesta
  2. 02Shell
  3. 03Remotes
  4. 04Tiempo real
  5. 05Jobs
  6. 06Tests unitarios
Fig. 05.1.2 Pipeline de entrega: cada merge recorre el mismo camino a producción.

Impacto

~50%

Despliegues más pequeños

~30%

Menos en la factura de AWS

2+

Años en la plataforma

8 rolesDónde pasó el trabajo

  1. 01Katapult LabsSenior Full Stack DeveloperPagos, API y CI/CD, de punta a punta2025 — Hoy
  2. 02NeuraTech Lead · Full Stack (medio tiempo)Un asistente con IA desde cero2025
  3. 03DevsuMobile & Frontend DeveloperPagos sin conexión para una billetera nacional2024 — 25
  4. 04GooDevFull Stack DeveloperArquitectura MySQL y pasarelas de pago2023 — 24
  5. 05Kuepa EdutechFull Stack DeveloperMicro-frontends, tiempo real y Redis2022 — 24
  6. 06IndependienteTutor de desarrollo webEnseñé desarrollo web y ayudé a estudiantes a conseguir trabajo2022 — 23
  7. 07AKE labFrontend DeveloperInterfaces drag-and-drop, Node y Oracle en AWS2021 — 22
  8. 08Editorial H&GFrontend DeveloperInterfaces con React y Redux2021
4 proyectosConstruidos en mi tiempo

1 CursoApuntes, no lecciones

Los cursos que he hecho, explicados como yo los entendí, con algo para probar en cada idea.

Todo el aprendizaje →
EscríbemeFin del portafolio

Disponible para roles remotos de Full Stack y desarrollo aumentado con IA. Trabajo en inglés todos los días: dailies, planeación, code reviews y reuniones con clientes.

rjuandavid1002@gmail.com
© 2026 Juan RamírezCompuesto en Inter Tight y JetBrains MonoHecho con Next.js y GSAP