Software a medida
Cuando la herramienta que necesitas no existe, la construimos.
Desarrollo de software a medida para empresas. Diseñamos y desarrollamos software alrededor de problemas concretos: plataformas internas, aplicaciones, portales, herramientas operativas y sistemas especializados que no pueden resolverse bien con una solución genérica.
No empezamos preguntando qué tecnología quieres usar. Empezamos entendiendo qué debe hacer el software, quién lo utilizará, qué información necesita, qué reglas debe ejecutar y con qué sistemas tendrá que convivir.
- Necesitamos que cada solicitud pase por revisión antes de aprobarse
- Esto debería calcularse solo
- Ahora lo hacemos con tres hojas y correos
- Los clientes necesitan ver el estado de su pedido
Comprar, configurar o construir
No todo necesita software a medida.
Si una herramienta existente resuelve bien el problema, usarla suele ser la decisión sensata. El software a medida tiene sentido cuando el proceso, la lógica, la integración o la experiencia son lo bastante específicos como para que lo genérico empiece a generar fricción.
Comprar, configurar o construir
¿Encaja lo que ya existe?
Construir
No encaja en lo esencial
Diseñar el sistema alrededor del problema. Aquí es donde este servicio tiene sentido.
Señales de que lo genérico está generando fricción
- Campos y hojas paralelas para cubrir lo que falta
- Personas haciendo de puente entre herramientas
- Reglas del negocio que la herramienta no puede modelar
- Una experiencia que no se puede adaptar al cliente
Recomendar la opción correcta, aunque no sea construir, forma parte del trabajo.
Cuándo el software a medida es la respuesta
La distancia entre lo que existe y lo que el negocio necesita.
El software genérico cubre lo común. El problema aparece en la distancia entre eso y lo que tu operación o tu producto necesitan de verdad. Estas son las formas que suele tomar esa distancia.
Lo que existe
- Contactos
- Tareas
- Informes
- Ajustes
La distancia
La herramienta que necesitas simplemente no existe.
Las herramientas existentes resuelven solo una parte del problema.
Procesos importantes viven entre varias aplicaciones.
Un flujo crítico se ha construido en hojas de cálculo.
Personas ejecutan a mano una lógica que el software podría aplicar.
La experiencia de uso tiene que ser específica del negocio.
El producto depende de reglas o datos propios.
Las integraciones son demasiado centrales para tratarlas como añadidos.
El crecimiento convierte el trabajo manual en complejidad operativa.
Hay una idea que ahora necesita convertirse en software real.
Lo que el negocio necesita
- Contactos
- Tareas
- Informes
- Ajustes
- Reglas propias
- Flujo entre sistemas
- Integraciones críticas
- Experiencia propia
Cuanto más específica es la distancia, más sentido tiene cerrarla con software diseñado para ella.
Qué significa «a medida»
No partimos de una plantilla. Diseñamos las piezas que necesita el problema.
Una aplicación a medida no es una web con más funciones. Es un conjunto de capas diseñadas para un problema concreto. Selecciona una capa para ver qué decide.
Capas del sistema
01 · Interfaz
¿Cómo se interactúa con él?
Pantallas diseñadas para el trabajo real de cada persona: las acciones correctas en el lugar correcto, y nada que no haga falta.
- Panel del equipo
- Portal del cliente
Las pantallas son la primera capa que se ve. Las ocho que hay debajo son las que hacen que el software resuelva el problema.
Qué construimos
Software agrupado por lo que necesita el cliente, no por tecnología.
Selecciona un tipo de software para ver cómo cambia la superficie del producto. Son categorías de intención; un proyecto real suele combinar varias.
| Solicitud | Cliente | Estado | Responsable |
|---|---|---|---|
| 4821 | Vela Distribución | En revisión | M. Serra |
| 4822 | Taller Delta | Recibida | — |
| 4818 | Grupo Aral | Aprobada | L. Vidal |
Superficies ficticias que ilustran cada tipo de software. No son productos de clientes.
El nombre de la categoría importa poco. Lo que importa es qué tiene que hacer el software y para quién.
La interfaz es solo la parte que se ve
No construimos pantallas. Construimos el sistema que hay detrás.
Lo que el usuario ve es la superficie. Debajo hay un modelo de datos, lógica de negocio, permisos, flujos, integraciones, automatización e infraestructura. Ahí está la mayor parte del trabajo, y ahí se decide si el software sigue funcionando dentro de un año.
- 01Modelo de datosQué existe y cómo se relaciona
- 02Lógica de negocioReglas, cálculos y decisiones
- 03PermisosQuién puede ver y hacer qué
- 04FlujosEstados y siguientes pasos
- 05IntegracionesSistemas con los que convive
- 06AutomatizaciónLo que ocurre solo
- 07InfraestructuraDónde funciona y cómo se despliega
Un proyecto que empieza por las pantallas suele acabar reconstruyendo todo lo demás.
Patrones, no casos inventados
Problemas de software que se repiten, y la forma que suele tomar la solución.
No son proyectos de clientes: son patrones de necesidad que aparecen en empresas muy distintas, con el tipo de sistema que suele resolverlos.
- 01
Un equipo tiene que revisar solicitudes
Aplicación de flujo de trabajo
Patrón · no es un caso de cliente - 02
Un cliente necesita acceder a su propia información
Portal de cliente
Patrón · no es un caso de cliente - 03
Una decisión depende de varias fuentes de datos
Aplicación de datos
Patrón · no es un caso de cliente - 04
Un proceso atraviesa varios sistemas externos
Plataforma con las integraciones en el centro
Patrón · no es un caso de cliente - 05
Un producto requiere cálculos propios
Motor de lógica a medida
Patrón · no es un caso de cliente - 06
Un servicio necesita un recorrido de usuario específico
Aplicación a medida
Patrón · no es un caso de cliente
Si tu situación se parece a alguno de estos patrones, ya sabemos por dónde empezar la conversación.
Lógica de negocio
El valor suele estar en las reglas que el usuario no ve.
La diferencia entre una web y un sistema serio está en la lógica que ejecuta: cálculos, condiciones y decisiones que se aplican igual cada vez, sin depender de que alguien se acuerde. Elige una entrada de ejemplo y mira cómo la evalúa el motor.
Entrada
- Importe
- 7.800 €
- Departamento
- Operaciones
- Proveedor
- Homologado
- Presupuesto restante
- 12.400 €
Reglas
- Importe superior a 5.000 € → aprobación de dirección…
- Proveedor homologado…
- Dentro del presupuesto del departamento…
Decisión
Requiere aprobación de dirección
Acción
Se asigna a dirección con plazo de dos días y se avisa al solicitante
Qué puede codificar la lógica
- Cálculos
- Elegibilidad
- Validación
- Estados
- Dependencias
- Permisos
- Plazos
- Emparejamiento
- Recurrencia
- Enrutamiento
- Aprobaciones
Valores ficticios. Las reglas reales se definen con la empresa y se prueban con casos concretos.
Cuando las reglas viven en el sistema, dejan de vivir en la cabeza de alguien.
Flujos y estados
Un proceso suele tener más estructura de la que el software genérico puede expresar.
Un flujo de ejemplo con cinco estados. Selecciona uno para ver qué controla: acciones disponibles, datos obligatorios, responsable, documentos, automatización, avisos y siguiente estado.
Acciones disponibles
- Aprobar
- Devolver
- Escalar
Datos obligatorios
Evaluación y comentario
Responsable
Revisor asignado
Documentos
Justificantes adjuntos
Avisos
Revisor asignado
Automático
Plazo de revisión a tres días → recordatorio
Siguiente estado
Flujo de ejemplo. Los estados reales, y lo que controla cada uno, se definen con la empresa.
Un estado bien definido responde solo a la pregunta «¿y ahora qué?».
Automatización dentro del producto
El software puede ejecutar por sí mismo el trabajo que se repite.
No es un producto de automatización aparte: es parte de la arquitectura. Cuando ocurre algo, el sistema comprueba una condición y actúa. Un registro de ejemplo de una mañana cualquiera:
- 09:02EventoRegistro creadoCondiciónTiene los datos mínimosAcción del sistemaSe enriquece y se clasificaResultadoListo para revisión sin trabajo manual
- 09:15EventoPlazo cercanoCondiciónFaltan menos de dos díasAcción del sistemaAparece en la lista de acción del responsableResultadoNada vence sin que alguien lo vea
- 10:40EventoCambio de estadoCondiciónEstado = aprobadaAcción del sistemaAviso y sincronización con el sistema externoResultadoTodos los sistemas coinciden
- 11:05EventoDocumento recibidoCondiciónEs un tipo reconocidoAcción del sistemaExtracción y estructuración de los datosResultadoSin transcribir a mano
- 12:30EventoCondición cumplidaCondiciónTodas las comprobaciones en verdeAcción del sistemaEl proceso avanza al siguiente estadoResultadoEl expediente se mueve solo
- 13:12EventoEvento externoCondiciónPago confirmado por la pasarelaAcción del sistemaSe actualiza el registro y se notificaResultadoEstado real, sin conciliar a mano
Ejemplos de lo que puede diseñarse. Qué automatizar, y con qué umbrales, se decide en cada proyecto.
La automatización bien hecha no se nota: simplemente hay menos trabajo.
IA dentro del software a medida
IA cuando el problema necesita entender, clasificar o generar.
La IA tiene sentido para lo que las reglas no pueden hacer: leer texto libre, interpretar documentos, resumir conversaciones o redactar. Para todo lo demás, la lógica determinista sigue siendo la respuesta correcta. Saber cuándo no usarla forma parte del diseño.
Motor de reglas
DeterministaMismo resultado cada vez. Auditable. Para cálculos, validaciones, permisos, estados y plazos.
- Cálculo de importes
- Elegibilidad
- Validación de datos
- Permisos
- Plazos
Modelo de IA
ProbabilísticoEntiende lenguaje y contenido. Necesita revisión o validación. Para extraer, clasificar, resumir y redactar.
- Texto libre → campos estructurados
- Documento → datos extraídos
- Pregunta → respuesta con datos del sistema
- Conversación → clasificación
- Contenido → borrador asistido
Cómo conviven en un mismo flujo
- 01 · IALa IA extrae importe, fecha y proveedor de una factura en PDF
- 02 · ReglasLas reglas validan el formato, comprueban el proveedor y deciden si requiere aprobación
- 03 · PersonaUna persona revisa cuando la confianza es baja o el importe es alto
En Life Admin, la extracción de documentos pasa por un esquema cerrado con validación en cliente y servidor; en el CRM inmobiliario, la IA atiende llamadas y redacta borradores siempre con revisión humana.
La IA aporta comprensión. Las reglas aportan garantías. El software a medida necesita las dos, cada una en su sitio.
Integraciones
Lo nuevo no debería obligarte a empezar de cero.
Casi todo software a medida convive con herramientas que ya existen. El sistema nuevo pasa a formar parte de un ecosistema: lee, escribe, sincroniza o reacciona a eventos según lo que cada conexión necesite. Selecciona un sistema.
ERP
- Leer
- Escribir
- Sincronizar
- Eventos
Pedidos, facturas y stock coherentes entre los dos sistemas.
Las conexiones posibles dependen de cada herramienta y de su acceso. Se estudian en el proyecto.
Integrar bien es lo que permite construir sin destruir lo que ya funciona.
Empezar de cero o partir de lo que existe
Un proyecto no siempre empieza en blanco.
Hay cuatro puntos de partida legítimos. No son paquetes: son situaciones desde las que se diseña el proyecto.
Evolucionar
Un sistema existente funciona, pero necesita lógica, módulos o interfaces nuevas.
El punto de partida cambia el plan. No cambia la exigencia.
Arquitectura
La arquitectura correcta depende de lo que el software tiene que hacer.
No elegimos la tecnología antes de entender el problema. Activa restricciones de ejemplo y mira cómo cambia la composición del sistema.
Restricciones del proyecto
Composición resultante
- 01AplicaciónPortal en React con autenticación, cuentas y roles; API en Node.jsUsuarios externos: clientes o socios
- 02DatosPostgreSQL con un modelo diseñado para la operación
- 03IntegracionesAPI REST y webhooks
- 04InfraestructuraLímites de peticiones, registros de acceso y entornos separadosUsuarios externos: clientes o socios
Composición ilustrativa. La arquitectura real se decide con los requisitos concretos de cada proyecto.
Criterios que pesan en la decisión
- Usuarios
- Complejidad
- Datos
- Seguridad
- Integraciones
- Latencia
- Escala
- Despliegue
- Propiedad
- Mantenibilidad
- Ecosistema existente
Con qué construimos
- React
- Node.js
- Python
- PostgreSQL
- Odoo
- Base44
- Deno
- APIs REST
- Webhooks
- Infraestructura en la nube adecuada al proyecto
La tecnología es una consecuencia de las restricciones, no un punto de partida.
Calidad
Que funcione hoy no es suficiente.
El software a medida pasa a formar parte de la operación, así que tiene que sobrevivir a su entrega: entenderse, probarse, mantenerse, protegerse y evolucionar. Lo que sigue son hechos de sistemas que ya hemos construido, no promesas.
01
Construir
Código estructurado y legible, con el modelo de datos como primera decisión.
02
Probar
Pruebas automáticas sobre las reglas que importan y validación con casos reales.
03
Desplegar
Entornos separados, despliegue desde el repositorio y migraciones controladas.
04
Observar
Registros, trazas de auditoría y alertas donde el sistema lo necesita.
05
Evolucionar
Documentación y una arquitectura que admite cambios sin reescribir.
Hechos verificados en sistemas reales
- 939tests automáticos en 63 archivosLife Admin
- 81migraciones de esquema controladasCRM inmobiliario
- 88reglas de acceso por registro y 27 perfilesCRM inmobiliario
- HMACwebhooks firmados con marca de tiempo y claves con hashFivo
- 2FAobligatorio en cada inicio de sesión, con registros de auditoríaFivo
- Esquemacerrado para la IA, validado en cliente y servidorLife Admin
La calidad no es una fase final: es la forma de construir desde el primer día.
Prueba real
Tres problemas distintos. Tres sistemas distintos. Una misma capacidad.
No vendemos una tecnología: construimos el sistema que cada problema exige. Estos tres sistemas existen, están en uso y salieron de problemas que no se parecían en nada.
01 · Operaciones
CRM inmobiliario a medida
CRM Inmobiliario
InmueblesClientesOperacionesAgendaVisitasDocumentosWhatsAppFiltros
Zona
Tipo
Precio
Habitaciones
128 resultados
- Piso · Zona Norte€ 248.000REF-1042 · 3 hab · 2 baños · 92 m²Nuevo
- Ático · Centro urbano€ 195.000REF-2210 · 2 hab · 1 baño · 74 m²Reservado
- Chalet · Zona Sur€ 410.000REF-3078 · 4 hab · 3 baños · 180 m²Activo
- El problema
- Una operación inmobiliaria completa (propiedades, clientes, demanda, visitas, operaciones, documentos) repartida entre herramientas que no la entendían.
- En qué se convirtió
- El sistema operativo de la empresa sobre Odoo: modelos propios, estados, reglas, automatización, integraciones con portales y comunicación, e IA con revisión humana.
- La arquitectura que emergió
- OdooPythonPostgreSQLIntegraciones con portalesIA generativa
- 40K+propiedades gestionadas
- 20+módulos a medida
- 45procesos automáticos
02 · Administración personal
Life Admin
- El problema
- Facturas, suscripciones, renovaciones y garantías repartidas entre correos, PDF y notas, sin nada que calculara qué viene después.
- En qué se convirtió
- Un producto que convierte documentos en obligaciones estructuradas: términos congelados, ciclos derivados, pagos con evidencia y extracción asistida por IA bajo esquema.
- La arquitectura que emergió
- ReactBase44DenoLLM con esquema cerradoVitest
- 22entidades
- 12funciones de servidor
- 939tests
03 · Pagos
Fivo
- El problema
- Aceptar pagos con stablecoins en varias redes con una sola integración, con el cobro, la verificación en cadena y el movimiento entre redes dentro del sistema.
- En qué se convirtió
- Infraestructura de pagos completa: checkout, API con claves por entorno, webhooks firmados, panel para comercios, facturas y procesos de retiros y reembolsos.
- La arquitectura que emergió
- ReactNode.js + TypeScriptPostgreSQLNext.jsPuentes CCTP
- 9redes mainnet
- 3vías de integración
- 5eventos de webhook
Prueba realCifras verificadas en los repositorios de cada sistema. Los nombres de clientes y los datos privados se mantienen confidenciales; las superficies mostradas están saneadas.
Si las tres arquitecturas son distintas es porque los problemas lo eran. Eso es lo que significa «a medida».
Petición frente a sistema
No tomamos la pantalla pedida al pie de la letra. Descubrimos el sistema que hay detrás.
Una petición suele llegar con la forma de una pantalla: «necesitamos un panel», «necesitamos un portal». Debajo hay casi siempre un sistema. Selecciona una petición.
La petición
Lo que suele hacer falta
- 01Fuentes de datos
- 02Permisos
- 03Cálculos
- 04Reglas de negocio
- 05API
- 06Histórico
- 07Alertas
- 08Interfaz
- 09Despliegue
Tomar la petición en serio es preguntar qué tiene que pasar para que esa pantalla funcione.
Descubrimiento
No necesitas venir con un documento técnico.
Puedes venir con un problema, un proceso, una idea o una herramienta que ya no funciona como necesitas. Nuestro trabajo empieza convirtiendo esa necesidad en una definición clara del sistema. Estas son las preguntas que la construyen.
- Objetivo
- Revisar y aprobar solicitudes sin correos ni hojas paralelas
- Usuarios
- Equipo de operaciones, dirección y solicitantes externos
- Datos
- —
- Reglas
- —
- Automatización
- —
- Integraciones
- —
- Controles
- —
- Permisos
- —
- Indicadores
- —
Con estas respuestas, el sistema ya tiene forma antes de escribir una línea de código.
De qué nos hacemos responsables
Del problema al software en producción, con un solo responsable.
No necesitas reunir cinco proveedores. El proyecto puede cubrir todo el recorrido:
01
Entender
- Descubrimiento
- Definición funcional y de producto
02
Diseñar
- Experiencia e interacción
- Arquitectura
- Modelo de datos
03
Construir
- Interfaz
- Servidor y API
- Lógica de negocio
- Automatización
- IA cuando aporta
04
Conectar
- Integraciones
- Pruebas
- Migración de datos
05
Operar
- Despliegue
- Documentación
- Mantenimiento y evolución
El alcance se ajusta a cada proyecto. La responsabilidad, no.
Cómo trabajamos
Un proyecto de software a medida, paso a paso.
01
Entender
Problema, usuarios y resultado esperado.
02
Definir
Requisitos, flujos y límites del sistema.
03
Arquitectar
Datos, lógica, integraciones y base técnica.
04
Construir
Software funcionando, por iteraciones.
05
Validar
Escenarios reales, pruebas y feedback.
06
Desplegar
Producción y migración cuando hace falta.
07
Evolucionar
El software cambia cuando cambia el negocio.
Para quién
Software a medida tiene sentido cuando el problema es específico de verdad.
Encaja cuando
- Las herramientas existentes no resuelven el problema principal
- El propio flujo de trabajo crea valor para el negocio
- La lógica propia importa
- Varios sistemas tienen que actuar como uno
- La aplicación pasa a formar parte de la operación diaria
- Los usuarios necesitan una experiencia construida para ellos
- El software es parte del producto o del servicio que se entrega
No es la mejor opción cuando
- Una herramienta estándar ya resuelve bien el problema
- Solo hace falta una personalización superficial
- No hay un problema operativo o de producto claro
Si encaja, hablemos. Si no encaja, también te lo diremos.
Tu software
Cuéntanos qué necesitas que exista.
No hace falta que sepas cómo construirlo ni qué tecnología utilizar. Explícanos el problema, quién lo vive y qué debería ocurrir. Nosotros nos encargamos de convertirlo en un sistema.