Ir al contenido

Guillermo Natali Ulla

Software Engineer especializado en infraestructura y Backend.

Software Engineer / Backend Lead en una consultora de software. Backend e infraestructura son mi especialidad, y construí varios productos enteros: base de datos, API, front y servidor.

Llevando sistemas a producción y sosteniéndolos después

Guillermo Natali Ulla
sistemas en producciónhoy
  • mensajería omnicanal45 cuentas
  • skin studiomicaskin.com
  • vps multi-app6 servicios

+500.000

Mensajes entrantes por mes en la plataforma que lidero

45

Cuentas en producción sobre una sola instancia

3

Sistemas que diseñé y sigo sosteniendo

3

Años de experiencia construyendo soluciones

Lo que uso todos los días

  • PostgreSQL
  • Django
  • Django Ninja
  • Ruby on Rails
  • Docker
  • Nginx
  • Caddy
  • Redis
  • Sidekiq
  • Celery
  • n8n
  • GitHub Actions
  • JavaScript
  • React
  • Next.js

Quién soy

Empecé desarmando máquinas para ver cómo funcionaban por dentro. Sigo haciendo lo mismo.

Vengo del campo. De chico ayudaba a mi papá a desarmar máquinas: entender cómo funcionaba algo por dentro siempre fue la parte que me enganchaba. En 2015 armé mi primera PC solo y me metí con C++ para entender como es que lo que yo veía en la pantalla se construía.

En 2017 llegué a Python y se dio vuelta todo: cualquier idea que tuviera en la cabeza podía construirla de forma ágil y sencilla. Eso no lo solté más. Aprendí solo durante años, entre cursos, terminal y lógica pura, y en la pandemia sumé web, front y frameworks.

En 2022 arranqué un terciario y en 2024 me recibí de Técnico Superior en Desarrollo de Software. La facultad la curso en paralelo, hoy en quinto año. El impulso sigue siendo el mismo que a los quince: abrir la "máquina" y ver cómo funciona.

Competencias

  • Backend y APIs

    Django, Django Ninja y Rails sobre PostgreSQL. APIs tipadas, colas con Sidekiq y Celery, reglas de negocio en la base. Hoy sostengo una plataforma multi-tenant con más de 500.000 mensajes por mes.

  • Infraestructura y despliegue

    Docker, Nginx y Caddy, TLS y pipelines de CI/CD con GitHub Actions. Administro un servidor propio con seis servicios en producción y dejo el despliegue reproducible para que cualquiera del equipo pueda hacerlo.

  • Producto completo

    Especialista en backend, pero construí varios productos enteros: base de datos, API, front en React o Next.js y el servidor donde corren. Skin Studio es uno de ellos y es público.

Los tres casos son el mismo problema.

Cosas que tienen que convivir sobre un sustrato compartido sin pisarse: clientes en una instancia, reglas en un modelo, aplicaciones en un servidor. El aislamiento no lo pone la interfaz, lo pone el diseño de abajo.

  • 1 instancia → N clientes

    Una sola instancia atiende a 45 cuentas, y cada una tiene su número de WhatsApp y su bandeja sin ver jamás la conversación de la otra.

  • 1 dominio → N reglas

    Las reglas del negocio vivían como acuerdos tácitos y se rompían en cada excepción; ahora están en el modelo, cada una con su test.

  • 1 servidor → N apps

    El patrón con el que hospedo seis aplicaciones en producción, incluido este sitio. Una app nueva entra sin tocar ninguna de las que ya corren.

Cómo trabajo

Cuatro pasos, siempre en el mismo orden

Es la secuencia que uso en todos los proyectos, y la razón por la que las reglas del negocio no se rompen cuando aparece la primera excepción.

  1. 1

    Entender el negocio

    Qué puede pasar, qué nunca puede pasar, y qué excepciones ya existen aunque nadie las haya escrito.

  2. 2

    Modelar los datos

    Diseño el modelo según lo pida el problema, en una base relacional o documental. Las reglas innegociables viven en la capa de datos: constraints, transacciones y validaciones de esquema, no en la interfaz.

  3. 3

    Desplegarlo

    Un compose por app, reverse proxy central, TLS automatizado y CI/CD. El despliegue es parte del desarrollo, no un paso que se delega: el equipo puede sacar cambios el mismo día.

  4. 4

    Sostenerlo

    Actualizar, responder cuando algo se rompe y volver sobre las decisiones cuando el negocio cambia. Entregar es la mitad del trabajo.

Casos

Tres sistemas en producción

Los clientes van por rubro, no por nombre. Cada caso tiene su página con el problema, la decisión técnica y el resultado.

1 servidor → N appsInfraestructura propia

VPS multi-app

El patrón con el que hospedo seis aplicaciones en producción, incluido este sitio. Una app nueva entra sin tocar ninguna de las que ya corren.

Archivos para agregar una app
2
Puertos de base publicados
0
Apps que hay que reiniciar
0
Certificados que renovar a mano
0

La diferencia

El camino corto y el que aguanta

Lo que se suele hacer

  • Una instalación entera por cliente, con su servidor, sus updates y sus certificados
  • Las reglas del negocio validadas en el formulario, y otra vez en cada pantalla nueva
  • Bases con el puerto abierto al mundo porque era más rápido así
  • El deploy lo hace otro equipo, y cada cambio espera su turno

Cómo lo resuelvo

  • Una instancia multi-tenant, con el cliente resuelto en el borde por su identificador
  • Las reglas innegociables en PostgreSQL, con constraints, transacciones y su test
  • Bases en red interna, sin un solo puerto publicado hacia afuera
  • El deploy está automatizado y documentado: un compose, un conf, y sale el mismo día

Stack

Con qué trabajo, y para qué

Una herramienta entra a esta lista cuando la puse en producción y la sostuve. Lo que estoy aprendiendo lo digo como tal.

PostgreSQLLógica atómica y constraints en la base, no en la aplicación. SQL avanzado.Dónde: Mensajería omnicanal · Skin Studio
MySQL, MongoDB, FirebaseRelacional o documental según lo pida el modelo. Firebase para auth y datos en tiempo real cuando no se justifica un backend propio.Dónde: API Compras · proyectos de auditoría
Python, DjangoDRF y Django Ninja para APIs tipadas con Pydantic.Dónde: Skin Studio
Ruby on RailsExtiendo y sostengo una plataforma open source en producción.Dónde: Mensajería omnicanal
Docker, Nginx, CaddyUn compose por app, reverse proxy central, TLS con Certbot.Dónde: VPS multi-app
GitHub ActionsPipelines de build y despliegue automatizado hacia mis propios servidores.Dónde: VPS multi-app
Sidekiq, Celery, RedisTodo lo que no puede bloquear una request.Dónde: Mensajería omnicanal · Skin Studio
IntegracionesWhatsApp Cloud API, MercadoPago, Google Calendar, n8n, Evolution API.Dónde: Mensajería omnicanal · Skin Studio
JavaScript, React, Next.jsEl front de los productos que construí enteros, en TypeScript. React y Vite donde ya existía.Dónde: Skin Studio · este sitio
GoEn crecimiento. Todavía no lo puse en producción.Dónde: —

Trayectoria

Dónde estuve y qué me llevé

  1. Octubre 2025 — hoy

    Software Engineer / Backend Lead

    Consultora de software · remoto

    Liderar el backend de una plataforma multi-tenant en producción: decidir la arquitectura, sostenerla bajo carga y responder cuando algo se rompe.

  2. Enero — octubre 2025

    Backend Developer

    E-commerce en producción

    Diez meses construyendo módulos y plantillas personalizadas reutilizables entre proyectos. Fue mi primer contacto con ciclos de desarrollo, despliegue e infraestructura reales.

  3. 2022 — hoy

    Formación

    Téc. Sup. en Desarrollo de Software, ISBL (recibido en 2024) · Ing. en Sistemas Informáticos, UAI — 5.º año

    Las bases que uso todos los días: modelado de datos, algoritmos y bases de datos relacionales.

  4. 2015 — 2021

    Autodidacta

    C++, Python, terminal y lógica pura

    Siete años aprendiendo solo, sin nadie que me corrigiera. Ahí agarré la costumbre de leer el código de otros hasta entenderlo, que es lo que hago hoy cuando extiendo una plataforma que no escribí.

¿Tenés un sistema que tiene que funcionar en producción y sostenerse?

Lo diseño, lo construyo entero y me hago cargo de que siga andando. Escribime y hablamos. Respondo en el día.