Glosario
El vocabulario que usamos durante un proyecto.
Términos que aparecen seguido en propuestas, llamadas y entregas. Definimos cada uno en lenguaje claro, sin jerga innecesaria, para que cualquier persona del equipo del cliente entienda cómo se mueve un proyecto con nosotros.
Tipos de proyecto que tomamos
- Prototipo funcional
- Versión navegable y conectada del producto, hecha rápido y con un stack desechable. Sirve para validar la idea con usuarios reales antes de invertir en un MVP completo. No es código pensado para escalar: se descarta una vez tomada la decisión.
- MVP (Producto Mínimo Viable)
- Primera versión funcional del producto, construida sobre una arquitectura y un modelo de datos pensados para crecer. Incluye lo necesario para usuarios reales: cuentas, lógica completa, pagos cuando corresponde y telemetría base. A diferencia del prototipo, está pensado para que el código siga vivo.
- SaaS y micro-SaaS
- Software-as-a-Service: aplicación web que clientes externos usan por suscripción. Un micro-SaaS es lo mismo pero enfocado en un nicho específico, con menos funcionalidades y operación más liviana. Suelen requerir cuentas, pagos recurrentes, panel de administración y onboarding.
- Aplicación web a medida
- Plataforma interna construida para una organización en particular: captura de datos, lógica de proceso, permisos por rol y reportería sobre una sola fuente de verdad. Reemplaza planillas, formularios dispersos y herramientas que no se comunican entre sí.
- Aplicación móvil
- Aplicación que vive en el teléfono del usuario final y se conecta al mismo backend que la plataforma web. Pensada para escenarios donde el navegador no alcanza: notificaciones push, uso offline, captura desde la cámara o cuando el caso de uso es estrictamente móvil. La definición exacta (web mobile-first, app multiplataforma o caso particular) se decide caso a caso según restricciones del proyecto.
- Integraciones y automatización
- Capa que conecta herramientas que ya usa la empresa (CRM, ERP, facturación, calendarios, APIs internas) y automatiza flujos repetitivos que hoy ejecuta alguien a mano. Sincronización vía API, webhooks o trabajos programados, con monitoreo y manejo de errores incluidos.
- Landing page
- Página de aterrizaje pensada para una sola acción: capturar interés de un producto, conseguir leads para un lanzamiento o validar un mensaje antes de construir más. Suele acompañar el lanzamiento de un SaaS o de una funcionalidad concreta, con foco en velocidad de carga y conversión.
- Consultoría y auditoría técnica
- Discovery para proyectos nuevos, revisión de sistemas existentes o due diligence técnica para inversiones o adquisiciones. Entregable principal: un documento con hallazgos, riesgos y recomendaciones priorizadas. No incluye construcción.
Cómo se mueven los proyectos
- Discovery
- Fase acotada y pagada al inicio del proyecto donde mapeamos flujos, datos y restricciones reales antes de proponer alcance. Entregable: documento de arquitectura, riesgos y propuesta cerrada por fases.
- Brief
- Resumen estructurado que nos manda el cliente desde el formulario de contacto: tipo de proyecto, presupuesto, plazo y descripción del problema. Es el punto de partida antes de la llamada inicial.
- Alcance
- Lista explícita de qué entra y qué NO entra en el proyecto. Lo escribimos en la propuesta para evitar sorpresas a mitad de camino. Cuando el cliente pide algo nuevo a mitad, se evalúa por separado como cambio de alcance.
- Sprint
- Ciclo de trabajo de una semana con una demo en vivo al final. Vemos lo que se construyó, ajustamos prioridades y cerramos lo que toca el sprint siguiente. Sin reuniones de seguimiento que solo justifiquen horas.
- Roadmap
- Lista priorizada de qué se va a construir y en qué orden, con plazos aproximados. Lo mantenemos vivo durante el proyecto y se actualiza cuando aparece información nueva.
- Traspaso
- Última fase del proyecto: entregamos el código, repositorio, credenciales, documentación y una sesión de onboarding al equipo que va a mantener el sistema. Todo queda a nombre del cliente.
De qué hablamos cuando hablamos de datos
- Modelo de datos
- Definición de qué entidades existen en el sistema, qué información guarda cada una y cómo se relacionan entre sí. Es la base sobre la que se construye todo lo demás. Un modelo mal pensado al inicio se paga durante años.
- Diagrama entidad-relación (ER)
- Representación visual del modelo de datos. Cajas para cada entidad, líneas entre ellas para las relaciones. Es uno de los primeros entregables de cualquier proyecto, antes de escribir código.
- Base de datos relacional
- Tipo de base de datos organizada en tablas que se relacionan entre sí. PostgreSQL es nuestra opción por defecto: probada, neutral en vendor y entendida por todo el ecosistema.
- Migración
- Cambio controlado de la estructura de la base de datos (agregar columnas, crear tablas, mover información) sin perder los datos existentes ni romper el sistema en producción.
- Stack
- Conjunto de tecnologías que componen el sistema: lenguaje, framework, base de datos, infraestructura, servicios externos. Lo elegimos por costo operativo y mantenibilidad, no por tendencia.
Lo que aparece dentro de la aplicación
- Autenticación y sesiones
- Mecanismos para que los usuarios se registren, inicien sesión y permanezcan identificados de forma segura. Incluye recuperación de contraseña y, cuando aplica, login con Google u otros proveedores.
- Permisos por rol
- Control de qué puede ver y qué puede hacer cada tipo de usuario dentro del sistema. Por ejemplo: un administrador edita todo, un operador solo crea, un auditor solo lee.
- API
- Forma estandarizada de comunicación entre sistemas. Si tu aplicación se comunica con un CRM, una pasarela de pago o un calendario externo, lo hace por una API. También podemos exponer tu propia API para que otros sistemas se integren.
- Integración
- Conexión funcional entre tu sistema y herramientas externas: CRM, facturación, pagos, calendarios, herramientas internas. Cada integración se prioriza explícitamente en la propuesta.
- Webhook
- Notificación automática que un sistema envía a otro cuando ocurre un evento (por ejemplo: "pago confirmado", "factura emitida", "nuevo lead"). Es la forma más eficiente de mantener dos sistemas sincronizados sin tener que consultarse cada cierto tiempo.
- Pasarela de pago
- Servicio que procesa cobros con tarjeta o transferencia. Stripe (internacional) y Mercado Pago (LATAM) son las dos que más usamos. Incluyen pagos únicos, suscripciones recurrentes, reembolsos y webhooks.
- Merchant of record (MoR)
- Proveedor que actúa como el vendedor oficial del producto frente al usuario final: emite la factura, cobra los impuestos correspondientes (IVA UE, sales tax US, etc.) y se hace cargo del compliance fiscal en cada país. Lemon Squeezy y Paddle son los más usados. Útil para vender SaaS internacional sin armar entidades legales en cada mercado.
- Multi-tenant
- Arquitectura donde una sola aplicación atiende a múltiples clientes (tenants) simultáneamente, manteniendo los datos de cada uno aislados. Es el modelo estándar de los SaaS: cada cliente entra a la misma app pero ve solo lo suyo. Implica decisiones específicas sobre el modelo de datos, permisos y separación lógica vs física de la información.
- Telemetría
- Eventos clave instrumentados dentro de la aplicación para que las primeras decisiones de producto se tomen con datos, no con intuición: registros, conversiones, uso de funcionalidades, errores.
- OTA update (over-the-air)
- Actualización de una aplicación instalada sin pasar por App Store o Google Play. Frecuente en apps móviles con Expo: cuando se cambia algo del lado de JavaScript (UI, lógica, copy) se publica directo y los usuarios lo reciben al abrir la app. Las revisiones de las tiendas solo son necesarias para cambios nativos o de configuración del binario.
Dónde corre el código
- Repositorio
- Lugar donde vive el código fuente (típicamente GitHub). Se crea en la cuenta del cliente desde el día uno. Todo cambio queda registrado con autor y fecha.
- Despliegue (deploy)
- Publicación de una nueva versión del software en el ambiente de producción. Lo hacemos de forma automatizada desde el repositorio, sin manipular servidores a mano.
- Producción y staging
- Producción es el ambiente donde corre la aplicación que usan los usuarios reales. Staging es una copia paralela donde probamos cambios antes de pasarlos a producción.
- Lanzamiento (go-live)
- Momento en que la aplicación queda accesible al público o al equipo final. Suele coincidir con la migración de los datos iniciales y el cambio de DNS al dominio definitivo.
- Hosting
- Servicio donde corre la aplicación. Elegimos según el caso: Cloudflare Workers para sitios y aplicaciones livianas, Vercel o Railway para proyectos con backend tradicional, AWS o GCP cuando hay requisitos de escala o cumplimiento específicos.
- CDN (Content Delivery Network)
- Red de servidores distribuidos geográficamente que sirven contenido estático (imágenes, CSS, JavaScript) desde el punto más cercano al visitante. Reduce los tiempos de carga, especialmente para usuarios lejos del servidor principal. Cloudflare es la CDN que viene incluida cuando deployamos sobre Workers.
- CI/CD
- Integración Continua y Despliegue Continuo. Conjunto de procesos automatizados que ejecutan tests al hacer un cambio en el código y, si todo pasa, lo despliegan a producción sin intervención manual. GitHub Actions y GitLab CI son las herramientas que más usamos. Acelera el ciclo de entrega y reduce el riesgo de subir cambios rotos.
- Backups y monitoreo
- Copias periódicas de la base de datos y observación automática del sistema. Si algo falla, llega un aviso antes de que el cliente lo note.
Cuando revisamos algo existente
- Auditoría técnica
- Revisión completa del código, base de datos y arquitectura de un sistema existente. Entregable: documento con hallazgos priorizados, riesgos detectados y recomendaciones concretas.
- Due diligence técnica
- Auditoría enfocada en evaluar el software de una empresa que se va a adquirir o en la que se va a invertir. Mide el estado real del producto, los riesgos ocultos y el costo estimado de saneamiento.
- Deuda técnica
- Trabajo pendiente que se acumula cuando se priorizó velocidad por sobre calidad. No es siempre mala: a veces se asume conscientemente. Lo importante es saber dónde está, cuánto cuesta y cuándo conviene pagarla.
- Refactor
- Reescribir partes del código sin cambiar lo que hace, para que sea más simple, más rápido o más fácil de mantener. Se hace por etapas, con tests que aseguran que nada se rompe en el camino.
¿Sigue habiendo algo que no cuadra?
Mejor preguntar antes de construir.
Si te encontraste con un término que no aparece acá o te quedó la duda igual, escríbenos. Cada llamada inicial es para entender el caso real, no para hacer venta.