Tipos de producto
Antes de construir cualquier cosa, la pregunta más importante es dónde va a vivir. El tipo de producto define las restricciones técnicas, los tiempos, los costos y lo que es posible hacer.
Web app
Corre en el browser desde una URL, sin instalación. Se actualiza automáticamente. Es el punto de partida más común y el más rápido de lanzar.
Mobile app
Vive en el App Store o Play Store. Tiene acceso a recursos del dispositivo como cámara, GPS o notificaciones push, pero requiere aprobación de Apple o Google para cada actualización.
Desktop app
Programa ejecutable instalado en la computadora. Puede funcionar offline y acceder a sistemas locales. Común en herramientas internas y software empresarial.
PWA (Progressive Web App)
Una web app que se comporta como mobile: se puede instalar desde el browser, recibir notificaciones y funcionar offline en ciertos casos. Es el punto medio entre web y mobile sin pasar por las tiendas.
Las tres capas de cualquier producto
Todo producto digital tiene tres capas. Entender en cuál vive un problema o una funcionalidad nueva es la diferencia entre una conversación productiva con tech y una que dura el doble.
Frontend
Todo lo que el usuario ve e interactúa. Muestra pantallas, captura acciones y da feedback inmediato. Las validaciones que importan de verdad no viven acá: si existen solo en el frontend, un usuario con conocimiento técnico puede saltearlas.
Backend
El cerebro del sistema. Decide qué puede pasar y cuándo: reglas de negocio, permisos, roles, integraciones con servicios externos, orquestación de flujos. Cuando algo "no se puede hacer" técnicamente, el límite casi siempre está acá.
Base de datos
La memoria del sistema. Guarda datos de usuarios, estados, historial de acciones y relaciones entre entidades. Es la fuente de verdad del producto. Si algo no llega a la base de datos, no existe.
Arquitectura
Conceptos que aparecen en conversaciones de producto y que conviene entender antes de que aparezcan en una reunión crítica.
API
El mecanismo por el cual dos sistemas se comunican. Integrar un servicio externo —pagos, emails o IA— implica conectarse a su API. Esa conexión tiene costos, límites de uso y dependencias que hay que contemplar desde producto.
Endpoint
Una dirección específica dentro de una API. Si la API es el edificio, el endpoint es la puerta exacta a la que llamás. Cuando un desarrollador dice "hay que crear un endpoint para eso", significa que hay que construir el punto de conexión que permita que esa acción ocurra.
Autenticación vs. Autorización
Autenticación es verificar quién sos (login, biometría, magic link). Autorización es decidir qué podés hacer una vez que el sistema sabe quién sos (permisos, roles, acceso a ciertas secciones). Son dos problemas distintos y se diseñan por separado.
Estado
La información que el sistema tiene en un momento dado y que puede cambiar. Un pedido puede estar "pendiente", "en camino" o "entregado". Diseñar bien los estados posibles de una entidad y las transiciones entre ellos es uno de los trabajos más importantes de producto, y uno de los que más fácil se ignora hasta que aparece un edge case en producción.
Webhook
La forma en que un servicio externo le avisa a tu sistema que algo pasó, sin que tu sistema tenga que estar preguntando constantemente. Cuando Stripe confirma un pago, manda un webhook. Es el mecanismo detrás de la mayoría de las integraciones en tiempo real.
Workflow de desarrollo
El camino de una idea a producción tiene pasos concretos. Entenderlos ayuda a dar fechas realistas, diagnosticar dónde está trabado algo y saber qué preguntar.
El flujo básico
El desarrollador escribe código en un editor (hoy típicamente Cursor o Claude Code), lo guarda en un repositorio local, lo sincroniza con GitHub, y desde ahí se hace un deployment a producción vía plataformas como Vercel. "Está hecho" y "está en producción" son dos cosas distintas.
Local
Donde se desarrolla y experimenta sin riesgo. Nada de lo que pasa acá afecta a usuarios reales.
Staging
El ambiente de validación previo a producción. Es donde se testean flujos completos, se detectan bugs y se alinean producto, diseño y tech antes de que algo salga.
Producción
Donde el producto vive. Usuarios reales, impacto real, métricas reales. Hacer cambios directamente en producción sin pasar por los otros ambientes es la causa de la mayoría de los incidentes evitables.
Git y control de versiones
Git registra todos los cambios que se hacen al código: quién los hizo, cuándo y por qué. Es el historial completo del proyecto. GitHub es la plataforma donde ese historial vive online y donde los equipos colaboran.
Branch
Una copia del código donde se trabaja de forma aislada sin afectar el resto. Main es el código en producción. Staging es el ambiente de validación. Las feature branches son temporales: se crean para una funcionalidad específica y se eliminan cuando se integran.
Commit
Una confirmación de cambios con un mensaje descriptivo. "fix: corregir validación de email en registro" le dice algo a cualquiera tres semanas después. "changes" no le dice nada a nadie.
Pull / Push
Pull trae los cambios del repositorio remoto a tu copia local. Push lleva tus cambios locales al repositorio remoto.
Pull Request
Una propuesta formal de integrar cambios de una branch al código principal. Otro miembro del equipo la revisa y aprueba antes de que se fusione. Es donde se documenta qué cambió y por qué.
Merge conflict
Ocurre cuando dos personas modificaron la misma parte del código en ramas distintas y Git no puede decidir automáticamente cuál versión conservar. Es uno de los motivos más comunes por los que algo "sencillo" tarda más de lo esperado.
Operación
Lo que pasa después de que algo sale a producción. Ignorar esta capa es uno de los errores más comunes en equipos que están creciendo.
Bug vs. deuda técnica
Un bug es un comportamiento incorrecto: algo que debería funcionar de una forma y no funciona así. La deuda técnica es código que funciona pero que fue escrito de una forma que hace más costoso cualquier cambio futuro. Los dos consumen capacidad del equipo, pero se priorizan distinto.
Deploy
Publicar una nueva versión del código en producción. Entender el ciclo de deploys del equipo es importante para dar fechas realistas hacia afuera.
Rollback
Revertir a una versión anterior cuando algo sale mal. Es el plan B de cualquier deploy y una de las razones por las que el control de versiones existe.
Feature flag
Un mecanismo para activar o desactivar una funcionalidad sin hacer un nuevo deploy. Sirve para lanzamientos graduales, tests con un porcentaje de usuarios, o apagar algo rápido si falla. Reduce el riesgo de cualquier lanzamiento.
Logs
Registros en tiempo real de lo que está pasando en el sistema. Cuando hay un incidente en producción, los logs son la primera fuente de diagnóstico.
Base de datos
La capa más ignorada en conversaciones de producto y la que más duele cuando está mal diseñada. Las decisiones de base de datos son las más difíciles de revertir.
SQL vs. NoSQL
Las dos grandes familias de bases de datos. Las bases SQL (como PostgreSQL) organizan la información en tablas con relaciones definidas. Son ideales cuando los datos tienen estructura clara. Las bases NoSQL (como MongoDB) guardan la información en documentos más flexibles. La mayoría de los productos de consumo usan SQL.
Esquema
La definición de cómo están organizados los datos: qué tablas existen, qué campos tiene cada una y cómo se relacionan. Cambiar el esquema después de que hay datos en producción es uno de los trabajos más delicados en desarrollo.
Migración
El proceso de modificar el esquema de una base de datos que ya tiene datos. Es uno de los motivos más comunes por los que algo que parece sencillo desde producto requiere más tiempo del esperado.
Índice
Una estructura que acelera las búsquedas en la base de datos. Los problemas de performance —páginas lentas, búsquedas que tardan, dashboards que no cargan— frecuentemente tienen origen en índices faltantes o mal diseñados.
Query
Una consulta a la base de datos. Cuando una pantalla muestra información, hay una o varias queries detrás. Pantallas con filtros cruzados o dashboards con agregaciones son más costosas de construir y servir que pantallas simples.
Transacción
Un conjunto de operaciones que se ejecutan como una unidad: o todas ocurren, o ninguna. En productos financieros o cualquier sistema donde la integridad de los datos es crítica, entender si las operaciones están correctamente transaccionadas es una pregunta de producto, no solo de ingeniería.
Backup
Una copia del estado de la base de datos en un momento dado. La frecuencia de los backups y el tiempo que tarda en restaurarse el sistema definen el peor escenario posible ante una falla.
Seguridad
No es un tema de engineering solamente. Muchas decisiones de seguridad las toma producto sin saberlo: qué datos se piden, dónde se guardan, quién puede verlos y cómo se accede al sistema.
HTTPS / SSL
El protocolo que encripta la comunicación entre el browser del usuario y el servidor. No es opcional ni es un detalle técnico: es el piso mínimo de cualquier producto con usuarios reales.
Variables de entorno
La forma en que se guardan credenciales y configuraciones sensibles fuera del código: claves de APIs externas, contraseñas de bases de datos, tokens de autenticación. Si esas claves se escriben directamente en el código y el repositorio es público, cualquiera puede verlas.
OAuth
El estándar detrás del "Login con Google" o "Login con GitHub". Reduce la fricción del registro y elimina la responsabilidad de guardar contraseñas, pero crea una dependencia con el proveedor externo.
Hashing de contraseñas
Cuando un usuario crea una contraseña, el sistema no debería guardarla tal cual: debería guardar una versión transformada e irreversible. Si la base de datos se compromete, nadie puede recuperar las contraseñas originales.
Encriptación
Transformar datos para que sean ilegibles sin la clave correcta. En productos con datos sensibles —salud, finanzas, información personal— la encriptación en reposo es frecuentemente un requisito regulatorio, no solo una buena práctica.
Rate limiting
Un mecanismo que limita cuántas requests puede hacer un usuario en un período de tiempo. Sirve para protegerse de ataques automatizados y bots. Desde producto, importa porque afecta la experiencia en casos legítimos: hay que diseñar el mensaje y el flujo de recuperación.
Principio de mínimo privilegio
Cada usuario, sistema o proceso debería tener acceso únicamente a lo que necesita para funcionar, y nada más. Es el principio correcto para diseñar quién puede ver qué y quién puede hacer qué.
Performance y escalabilidad
Performance es qué tan rápido responde el sistema hoy. Escalabilidad es si va a seguir respondiendo igual cuando haya diez veces más usuarios. Son problemas distintos, pero ambos empiezan con decisiones de producto.
Latencia
El tiempo que pasa entre que el usuario hace algo y el sistema responde. Por encima de 200ms el usuario empieza a percibir lentitud. Por encima de un segundo, la tasa de abandono sube de forma medible.
Caching
Guardar temporalmente el resultado de una operación costosa para no tener que repetirla cada vez. Es una de las optimizaciones de performance más efectivas y una de las que más bugs sutiles genera cuando está mal implementada, porque un caché desactualizado muestra información incorrecta.
CDN (Content Delivery Network)
Una red de servidores distribuidos geográficamente que sirven archivos e imágenes desde el punto más cercano al usuario. Reduce latencia y mejora la experiencia sin cambiar nada en el código de la aplicación.
Tiempo de carga vs. tiempo de respuesta
El tiempo de respuesta es cuánto tarda el servidor en procesar una request. El tiempo de carga es cuánto tarda la pantalla en estar completamente visible e interactiva. Una pantalla puede tener tiempo de respuesta rápido y tiempo de carga lento si carga muchos recursos pesados en el frontend.
Escalabilidad horizontal vs. vertical
Escalar verticalmente es poner más recursos en el mismo servidor. Escalar horizontalmente es agregar más servidores que distribuyen la carga. La horizontal es más flexible, pero requiere que la arquitectura esté diseñada para soportarla desde el principio.
Cuello de botella
El punto del sistema que limita la performance del conjunto. Optimizar cualquier otra parte sin resolver el cuello de botella no cambia la performance real. Identificarlo es el primer paso antes de cualquier trabajo de optimización.
Async vs. sync
Sync significa que el sistema espera a que una operación termine antes de continuar. Async significa que la operación se inicia y el sistema sigue sin esperar el resultado. Enviar un email de forma sync hace que el usuario espere. De forma async, la pantalla aparece inmediatamente y el email se envía en segundo plano.
IA en producto
Ya no es un tema de futuro. La IA está en la arquitectura de la mayoría de los productos nuevos, y entender cómo funciona técnicamente cambia cómo se diseña, qué se puede prometer y dónde están los límites reales.
LLM (Large Language Model)
El tipo de modelo detrás de ChatGPT, Claude o Gemini. No ejecuta instrucciones paso a paso: predice cuál es la continuación más probable de un texto dado su entrenamiento. El output nunca es 100% determinista. No tiene memoria entre conversaciones a menos que se la des explícitamente. Diseñar con LLMs implica aceptar variabilidad y construir los mecanismos para manejarla.
Contexto
La información que le pasás al modelo en cada llamada. Un LLM no recuerda la conversación anterior ni conoce tu sistema: lo que sabe en cada momento es exactamente lo que está en su contexto. Por eso la arquitectura de un producto con IA es en gran parte la arquitectura de qué información meterle al modelo, cuándo y en qué formato. El contexto tiene un límite de tamaño y tiene costo: más contexto, más caro y más lento.
Prompt
La instrucción que le das al modelo. En un producto real hay tres capas: el system prompt define el rol y las restricciones del modelo para toda la sesión; los prompts de contexto se construyen dinámicamente con datos del momento; el prompt del usuario es lo que escribe la persona. La calidad del output depende más de las dos primeras capas que de la tercera.
RAG (Retrieval Augmented Generation)
La técnica que resuelve el problema de que un LLM no conoce tu información interna. En lugar de reentrenar el modelo, se construye un sistema que busca la información relevante en el momento en que se necesita y la inyecta en el contexto. El modelo no "sabe" nada de tu empresa: lo lee en el contexto de cada llamada específica.
Embeddings
La forma en que el texto se convierte en números para encontrar información semánticamente similar, no solo por palabras exactas. Cuando buscás "cómo cancelo mi suscripción" y el sistema encuentra "dar de baja el plan", no es magia: es que ambas frases tienen embeddings cercanos. Es la tecnología que hace funcionar el RAG y la mayoría de los sistemas de búsqueda semántica.
Agente
Un sistema de IA que no solo responde sino que actúa. Recibe un objetivo, decide qué pasos seguir, ejecuta acciones, evalúa el resultado y decide qué hacer después. La diferencia con un LLM que responde preguntas es la autonomía en la secuencia. La mayoría de los productos de IA complejos son sistemas multi-agente, donde varios agentes especializados colaboran coordinados por un orquestador.
Alucinación
Cuando un LLM genera información que parece correcta pero es falsa. No lo hace con intención: es una consecuencia de cómo funciona la predicción de texto. En un chatbot de soporte es un problema de experiencia. En un sistema que toma decisiones de negocio es un riesgo operativo. Diseñar con IA implica saber dónde puede ocurrir y construir mecanismos para detectarlo o contenerlo.
Fine-tuning
El proceso de reentrenar un modelo base con datos propios para que adopte un comportamiento o conocimiento específico. Es más costoso y complejo que el RAG, pero útil cuando el problema no es de información sino de estilo o lógica que no se puede resolver con prompts. La mayoría de los casos en producto se resuelven antes con RAG y buenos prompts.
from021.io — get technical asap, from zero to one