La semana pasada estaba documentando la cuenta de Make de un cliente, apoyándome en Claude para dejar por escrito qué hacía cada cosa.
En la cuenta se mezclaban 4 tipos de escenarios:
- Escenarios que había montado desde cero yo, migrando desde Zapier.
- Otros que ayudé a montar al equipo.
- Otros que ya tenían de antes y los revisé/mejoré/optimicé.
- Y alguno que acordamos no tocar: porque los gestionaba alguien externo o porque no querían que yo me metiera ahí.
Unos 30 en total. Yo había metido mano en 28.
Después de un buen rato con Claude Code, se me ocurrió preguntarle:
«De los 30 escenarios hay 2 que yo no he hecho. Basándote en cómo están estructurados y montados en Make, ¿sabrías decirme cuáles NO son los míos?»
Acertó a la primera.
Así que le pedí los patrones que había detectado. Te los copio tal cual:
1. Una capa de «servicios» reutilizables, como si fueran funciones. Has creado una red de sub-escenarios que funcionan como servicios para 3 escenarios orquestadores más grandes.
2. Manejo de errores en capas, no «todo o nada». No solo contemplas rutas de error, también compruebas y envías notificaciones por canales prioritarios para gestionarlos más rápido.
3. Una taxonomía de emojis con significado. Cada escenario incluye 🤖⚡️🗓️✋🏻 para identificar el tipo de escenario que es según el trigger.
4. Documentas dentro de la propia herramienta. La mayoría de los «tuyos» llevan notas adhesivas explicando qué hace el escenario o qué devuelve (por ejemplo, en Holded – GET tickets fechas explicas los 4 campos que devuelve).
5. entradas y salidas como contrato. Cada sub-escenario reutilizable declara explícitamente qué recibe y qué devuelve, tratando el escenario como una función con firma definida.
Y su resumen: «tratas Make con mentalidad de ingeniería de software».
Pues mira, no me había parado a pensarlo así 😂.
Muchas de esas decisiones me vienen de los años de ingeniero. De encontrarme los mismos problemas una y otra vez y aprender qué soluciones aguantan cuando las cosas se complican.
Porque volver seis meses después a un escenario, entenderlo y cambiar una pieza sin miedo a cargarte otras tres… también hay que pensarlo.
- ✅ Cuándo conviene separar una parte para reutilizarla.
- ✅ Qué necesita recibir y qué debe devolver.
- ✅ Cómo gestionar un fallo para que te enteres a tiempo.
Ahí es donde entran los patrones de diseño. Te ayudan a reconocer problemas conocidos y a decidir cómo resolverlos.
Y aunque durante mucho tiempo lo confundí con intuición, experiencia o sentido común… la realidad es que eso se aprende.
Y «de eso» va el taller de mañana: tres horas para mirar un escenario y ver algo más que cuarenta pelotitas puestas en fila. Para entender dónde se está complicando y qué puedes hacer con él.
Mañana, jueves 17, de 16:00 a 19:00, hora de Madrid.
79 € con IVA incluido. 20 plazas. Y acceso a la grabación durante 3 meses por si el directo se te cruza con algo.
Santy 🫡
PD. Lo de los emojis en el nombre parece la tontería más grande de la lista y es lo que más agradeces cuando abres una cuenta con 30 escenarios. Dos segundos para saber qué dispara cada uno.
PD2: Si aún no montas tus escenarios en Make, te va a venir grande el taller. Pásate por LVL1 primero. Si ya tienes escenarios propios y sabes de alguno que te da guerra: reserva tu plaza, te lo traes y trabajas sobre él.