El problema que resuelve
Muchas empresas operan con una combinación de hojas de cálculo, sistemas genéricos y procesos manuales que se fueron acumulando con el tiempo. Funciona mientras el volumen es bajo, pero aparecen síntomas reconocibles: información que se digita dos veces, reportes que dependen de una sola persona, clientes que no pueden hacer por sí mismos lo que hoy requiere una llamada, y sistemas que obligan a adaptar el proceso a sus limitaciones.
El desarrollo de software a medida tiene sentido cuando el proceso es parte de lo que diferencia al negocio, o cuando las herramientas disponibles no pueden conectarse con el resto de la operación. No es la respuesta para todo: en muchos casos un producto existente es suficiente y más económico.
Cuándo conviene construir y cuándo no
Antes de escribir una línea de código conviene responder una pregunta honesta: ¿este proceso es lo bastante particular como para justificar un sistema propio? La siguiente tabla resume el criterio que usamos para orientar esa conversación.
| Situación | Suele convenir | Por qué |
|---|---|---|
| Proceso estándar (contabilidad, correo, planillas) | Producto existente | Son funciones maduras, reguladas o comoditizadas; reconstruirlas aporta poco. |
| Proceso central que diferencia al negocio | Software a medida | Permite reflejar reglas propias y evolucionar sin depender de la hoja de ruta de un tercero. |
| Producto existente que cubre el 80 % pero no se integra | Integración o extensión | A menudo basta con conectar el producto al resto de sistemas en lugar de reemplazarlo. |
| Experiencia para clientes finales (app, portal, pedidos) | Depende del alcance | Si la experiencia es parte de la propuesta de valor, el desarrollo propio da control; si no, una solución estándar puede bastar. |
| Sistema heredado difícil de mantener | Reemplazo gradual | Sustituir por partes reduce el riesgo frente a una migración total de una sola vez. |
Situaciones en las que resulta útil
- Portales y aplicaciones para clientes que necesitan consultar, solicitar, pagar o hacer seguimiento sin intervención manual.
- Herramientas internas que reemplazan hojas de cálculo compartidas por un sistema con roles, historial y validaciones.
- Aplicaciones móviles para personal en campo o para usuarios finales, conectadas con los mismos datos que la plataforma web.
- Paneles operativos que reúnen en un solo lugar información que hoy está repartida entre varios sistemas.
- Modernización de sistemas existentes que ya no pueden crecer o cuya tecnología dificulta encontrar quién los mantenga.
Cómo lo abordamos
Nuestro punto de partida es la operación: quiénes usan el sistema, qué hacen hoy, qué excepciones aparecen y con qué otros sistemas debe hablar. Esa comprensión define el alcance mucho mejor que una lista de pantallas.
- Entender la operaciónProcesos, usuarios, excepciones y sistemas involucrados.
- Definir el alcance inicialLa versión más pequeña que ya resuelve un problema real.
- Diseñar la arquitecturaModelo de datos, API, integraciones y seguridad.
- Construir por entregasIncrementos revisables con usuarios reales.
- Desplegar y acompañarPuesta en producción, monitoreo y ajustes.
Trabajar por entregas permite validar decisiones temprano. Es mucho más barato descubrir en la segunda semana que un flujo no encaja con la realidad que hacerlo después de construir todo el sistema.
Componentes habituales
No todos los proyectos necesitan todos los componentes, pero la mayoría de soluciones empresariales se construyen con piezas parecidas:
Concentrar las reglas de negocio en el backend, y no repartirlas entre la web y la app, evita que dos interfaces calculen distinto un mismo precio o estado. Profundizamos en esta decisión en el recurso web y móvil sobre un mismo backend.
Web, móvil nativa, multiplataforma o PWA
| Opción | Ventajas | Limitaciones |
|---|---|---|
| Aplicación web responsive | Una sola base de código, sin instalación, actualización inmediata. | Acceso limitado a funciones del dispositivo y a notificaciones en algunos sistemas. |
| PWA (aplicación web progresiva) | Se puede instalar, funciona parcialmente sin conexión. | El soporte de funciones varía según el sistema operativo y el navegador. |
| Multiplataforma (un código para Android e iOS) | Menor costo que dos apps nativas, buen acceso al dispositivo. | Algunas funciones muy específicas requieren código nativo. |
| Nativa por plataforma | Máximo rendimiento y acceso al dispositivo. | Dos bases de código que mantener y publicar. |
Consideraciones técnicas
- Modelo de datos primero. Las pantallas cambian con frecuencia; un modelo de datos mal planteado es mucho más costoso de corregir.
- API documentada. Diseñar el backend como una API facilita agregar nuevas interfaces e integraciones sin reescribir la lógica.
- Entornos separados. Desarrollo, pruebas y producción con datos y credenciales distintos.
- Pruebas automatizadas en las reglas de negocio críticas (cálculos, estados, permisos).
- Despliegues repetibles, idealmente automatizados, para que publicar una corrección no dependa de pasos manuales.
Seguridad
La seguridad se decide en el diseño, no al final. Los puntos mínimos que contemplamos son autenticación robusta, permisos por rol y por registro (que un usuario no pueda ver datos de otro cambiando un identificador en la URL), validación de toda entrada en el servidor, gestión de secretos fuera del código, cifrado en tránsito y actualización periódica de dependencias. Detallamos estos controles en seguridad de APIs: controles básicos que no deberían faltar.
Escalabilidad sin sobredimensionar
Diseñar para millones de usuarios desde el primer día suele encarecer y complicar un proyecto que todavía no los tiene. Preferimos decisiones que permitan crecer cuando haga falta: backend sin estado en memoria para poder agregar instancias, índices de base de datos alineados con las consultas reales, procesos pesados en segundo plano mediante colas y caché solo donde una medición lo justifique.
Operación y mantenimiento
Un sistema en producción necesita atención continua: actualizaciones de seguridad, monitoreo, respaldos verificados y ajustes a medida que cambia el negocio. Conviene acordar desde el inicio cómo se gestionarán incidencias, quién tendrá acceso a los entornos y dónde quedará la documentación técnica.
Relación con los productos de INTEDI
Los productos Fidelio, Clinovexis y Paybridge nacen de esta misma práctica de desarrollo. Cuando una necesidad coincide con lo que uno de ellos ya resuelve, puede convenir partir del producto y adaptarlo en lugar de construir desde cero.
Preguntas frecuentes
¿Cuánto tiempo toma desarrollar un sistema?
Depende del alcance, de las integraciones necesarias y de la disponibilidad de información. Por eso proponemos definir primero una versión inicial acotada: permite estimar con más precisión y empezar a obtener valor antes.
¿Es mejor una aplicación web o una app móvil?
Depende de quién la usa y en qué contexto. Si los usuarios necesitan funciones del dispositivo (cámara, ubicación, notificaciones) o trabajar sin conexión, una app suele justificarse. Si el uso es ocasional, una web responsive o una PWA suele ser suficiente.
¿Pueden continuar un sistema que desarrolló otro proveedor?
Es posible evaluarlo. Requiere acceso al código fuente, a la documentación disponible y a los entornos, y una revisión técnica previa para estimar el estado del sistema antes de comprometer cambios.
¿Quién es propietario del código desarrollado?
La titularidad del código y de la documentación se define en el acuerdo de cada proyecto. Recomendamos dejarlo explícito antes de iniciar.