El software interno suele nacer de una frase peligrosa: «Esto podríamos hacerlo nosotros». A veces es cierto. Pero poder construir una herramienta no demuestra que debamos mantenerla durante años.
En Emotia Labs tratamos el código como una fase del experimento. Antes hay una fricción que debe probarse. Después hay una operación, unos datos y una responsabilidad que seguirán existiendo cuando termine el entusiasmo del lanzamiento.
La primera decisión es comprar, integrar, simplificar o construir
Construir tiene sentido cuando la fricción es estratégica, frecuente y específica; cuando las alternativas obligan a adaptar demasiado el proceso; o cuando el aprendizaje generado forma parte de la ventaja de la empresa.
Comprar suele ganar cuando el problema es estándar —facturación, firma, calendario, CRM básico— y el mercado ya resuelve seguridad, soporte e integraciones a una escala imposible para un equipo pequeño.
El desarrollo a medida no elimina el coste de una licencia. Lo convierte en responsabilidad de producto.
Fase 1: definir el problema operativo
Documentamos un episodio real, no una categoría. Quién estaba trabajando, qué intentaba decidir, dónde se detuvo, cuánto costó y cómo salió del bloqueo. Después buscamos frecuencia.
La unidad de valor debe ser concreta: minutos hasta una respuesta, incidencias resueltas, documentos preparados, oportunidades cualificadas o pasos eliminados. «Digitalizar» no es una métrica.
Fase 2: usuario, decisión y flujo
Una herramienta interna puede tener pocos usuarios y aun así ser crítica. Definimos para cada rol qué ve, qué puede cambiar y qué decisión toma con la salida. Esto evita crear paneles llenos de información sin una acción asociada.
Fase 3: prototipo antes de arquitectura
Probamos el recorrido con pantallas estáticas, datos ficticios o un proceso manual detrás. El objetivo es descubrir vocabulario, pasos sobrantes, permisos y excepciones antes de consolidarlos en código.
Una conversación de veinte minutos con el usuario mientras completa una tarea revela más que una semana discutiendo el menú.
Fase 4: la arquitectura mínima que no nos encierre
Mínima no significa improvisada. Significa suficiente para el riesgo actual: autenticación, permisos, registro de acciones, copias, tratamiento de errores y separación clara entre datos y proveedor de IA si lo hay.
- Una sola ruta crítica bien resuelta.
- Roles mínimos y permisos explícitos.
- Datos de prueba antes de datos reales.
- Logs que permitan entender un fallo.
- Exportación para no secuestrar el conocimiento.
- Un proceso manual documentado como respaldo.
Fase 5: instrumentar antes de desplegar
El uso por sí solo no prueba valor. Medimos finalización del trabajo, tiempo, errores, abandono y necesidad de ayuda. Si incluye IA, registramos también correcciones humanas y tipos de fallo, sin almacenar más datos de los necesarios.
Fase 6: despliegue controlado
Empezamos con un grupo pequeño y un responsable del piloto. Durante una ventana definida, el flujo nuevo convive con el anterior. Así podemos detenerlo sin paralizar operaciones.
Las excepciones no se consideran ruido. Son material de diseño. Si una excepción aparece cada día, forma parte del producto.
Fase 7: decidir su futuro
Una herramienta interna puede escalar, permanecer pequeña, integrarse en otra plataforma o retirarse. El criterio se define de antemano: adopción de los usuarios objetivo, tiempo neto ahorrado, calidad, coste operativo y riesgo.
El criterio de retirada también es una funcionalidad
Define cómo exportar datos, volver al proceso anterior y comunicar el cierre. Un producto que no puede apagarse de forma segura no está bajo control.
Lo que el Lab nos obliga a aprender
Nuestro Lab reúne productos propios con naturalezas y estados distintos. Sostenible.ai trabaja sobre comunicación de sostenibilidad; Roasthisweb convierte una auditoría digital en un flujo de producto; Mobiliting, MiCurrito y Mi Ángel Guardián exploran otras fricciones específicas.
No usamos esta cartera para fingir que todo prototipo es un negocio consolidado. La usamos para demostrar una capacidad más importante: convertir una observación en hipótesis, construir lo necesario, exponerlo a realidad y decidir.
Errores que encarecen el desarrollo
- Copiar el proceso actual sin preguntarse qué paso sobra.
- Diseñar para todos los casos antes de dominar el principal.
- No nombrar a un propietario de producto.
- Añadir IA donde una regla sería más fiable.
- Medir entregables técnicos en vez de trabajo resuelto.
- Tratar mantenimiento, privacidad y soporte como asuntos posteriores.
Preguntas frecuentes
¿Qué diferencia hay entre SaaS interno y software a medida?
El SaaS interno suele ser una herramienta accesible como servicio para usuarios de la organización. El software a medida es una categoría más amplia. Ambos comparten responsabilidad de mantenimiento y evolución.
¿Cuándo conviene construir en vez de comprar?
Cuando la fricción es estratégica, frecuente y específica, y la ventaja o el aprendizaje compensan el coste total de propiedad.
¿La primera versión debe incluir IA?
Solo si la IA es necesaria para probar el valor. Si el riesgo principal es el flujo o la adopción, puede validarse primero con reglas o trabajo manual.
¿Qué debe medirse en un piloto?
Finalización, tiempo neto, errores, excepciones, necesidad de soporte y efecto sobre la decisión o resultado que motivó la herramienta.
¿Tienes una fricción que ninguna herramienta resuelve bien?
La analizamos como producto: problema, prueba mínima, coste de mantener y criterio para construir o no construir.
Sigue explorando
E
Emotia LabsLaboratorio de marketing: IA para acelerar, estrategia para decidir y personas para entender.
