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.
Lo que construimos para startups
- Landing de validación
- Página rápida y medible para probar si la idea le importa a alguien antes de construir el producto. Comunica la propuesta de valor, captura interés (leads, lista de espera o pre-venta) y mide cada paso de la conversión. La forma más barata de equivocarse menos.
- MVP (Producto Mínimo Viable)
- Primera versión real del producto, 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. No es un prototipo desechable: es la base sobre la que crece la startup.
- Aplicación web a medida (SaaS)
- El producto completo después del MVP: multiusuario con permisos por rol, facturación recurrente, panel de administración y arquitectura dimensionada para soportar el crecimiento real de usuarios y datos.
- Aplicación móvil multiplataforma
- App para iOS y Android desde una sola base de código (React Native / Expo), conectada al mismo backend que el producto web. Trabajamos multiplataforma, no nativo puro: es la mejor relación costo/velocidad para la mayoría de las startups.
- Diseño de producto (UX/UI)
- Flujos, interfaz y sistema de diseño que hacen que el producto se entienda y se use. No es la capa de pintura al final: es decidir qué ve el usuario, en qué orden y por qué. Va incluido en cada proyecto y también disponible por separado.
- Validación
- Poner una hipótesis del producto frente a usuarios reales para decidir con evidencia, no con intuición. Antes de construir, validamos que exista demanda; el aprendizaje alimenta directamente el MVP si se avanza.
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 o GitLab). 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 un MVP existente
- Auditoría técnica
- Revisión del código, base de datos y arquitectura de un MVP existente (normalmente heredado de otro proveedor). Entregable: diagnóstico honesto con hallazgos priorizados, riesgos y recomendaciones concretas.
- Rescate de MVP
- Retomar un producto construido por otro equipo cuando el código no está documentado y la base original ya no está. Decidimos contigo si conviene continuar sobre lo existente, rehacer módulos críticos o reescribir.
- 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.