Desarrollo de software
Imputación de horas en Salamanca
Una web corporativa no es un folleto: es lo primero que ve un cliente y, a menudo, lo que decide si te escribe. Tiene que cargar rápido en el móvil, poder leerse con un lector de pantalla y decir con claridad qué haces.
Los citizen developers —empleados que crean sus propias herramientas— son un activo si tienen un marco. Sin él, aparecen decenas de aplicaciones sin dueño, con datos sensibles en sitios inesperados. Ayudamos a poner ese marco sin frenar la iniciativa.
La automatización tiene coste de mantenimiento. Un robot que lee una web ajena se rompe cuando esa web cambia; un flujo que depende de la cuenta de un empleado se para cuando esa persona se va. Lo diseñamos pensando en quién lo va a mantener.
Del trabajo a la factura
El trabajo hecho se factura sin copiar datos, y el cobro vuelve a la ficha del cliente.
Por qué nos llaman
Una app propia que nadie mantiene
Se hizo una app hace años, las tiendas exigen actualizaciones y las librerías han quedado obsoletas. Ya hay usuarios que no pueden instalarla.
El programa estándar se queda corto
El software que compraste cubre la mayor parte del trabajo y el resto se hace a mano o con trucos. Ese resto es justo lo que diferencia tu forma de trabajar.
Flujos que dependen de un empleado
Automatizaciones montadas con la cuenta personal de alguien que se fue o cambió de puesto, y que dejaron de funcionar sin avisar.
Sincronizaciones nocturnas que llegan tarde
Los datos se pasan entre sistemas una vez al día. Durante el día, el equipo trabaja con información desactualizada.
Integraciones que fallan al desplegar
Dos equipos o proveedores cambian sus APIs por separado y la incompatibilidad se descubre en producción.
El resultado, en concreto
- Pruebas de contrato entre consumidores y proveedores de API, verificadas en integración continua.
- Registro de decisiones de arquitectura (ADR) con el porqué de cada elección técnica relevante.
- Límites de tiempo, reintentos y cortacircuitos en las llamadas a servicios externos.
- Canal de integración y despliegue continuo con pruebas automáticas y vuelta atrás.
- Documento de alcance con los flujos de trabajo acordados, lo que entra en la primera versión y lo que queda para después.
- Criterios de aceptación escritos y comprobables para cada funcionalidad.
- Integraciones entre sistemas con reintentos, idempotencia y gestión de errores documentada.
¿Hablamos de tu caso?
Reserva una llamada para ver nuestras propias herramientas en funcionamiento y valorar si algo parecido te encaja.
Guías de nuestra biblioteca técnica
Desarrollo y arquitectura
Patrón transactional outbox en arquitecturas de empresa
Flujo y contrato del evento
1. La aplicación valida la operación. 2. En una misma transacción, persiste el estado de negocio y la fila de outbox. 3. Un publicador o mecanismo CDC detecta la fila y emite el mensaje. 4. El consumidor valida el contrato, procesa el mensaje y registra su resultado. 5. La outbox se retiene y limpia según una política…
Leer la guía completaDesarrollo
Plantilla ADR para decisiones de arquitectura de software
Ejemplo — supuesto ilustrativo
Contexto: un portal de cliente necesita incorporar dos funciones nuevas, pero el equipo también debe reducir dependencias entre módulos. Opciones: ampliar el módulo actual, separar una capacidad detrás de una API o sustituir el portal completo. Decisión: no se elige una alternativa por defecto; el ADR debe registrar…
Leer la guía completaDesarrollo y arquitectura
Idempotencia en APIs y webhooks: reintentos sin duplicados
Consistencia y límites
Si el efecto de negocio y el registro de idempotencia se guardan en la misma base de datos, intenta confirmarlos en una transacción coherente. Para enviar eventos o llamar a otro servicio, define cómo deduplicar esa etapa —por ejemplo, un identificador de operación en una outbox— porque la transacción local no hace…
Leer la guía completaNuestro método
Contrato primero
Antes de programar, acordamos la API en OpenAPI con quien la va a consumir. Las discrepancias aparecen en un documento, no en producción.
Simulación y pruebas
Con el contrato se generan simuladores para que el consumidor avance en paralelo y pruebas que verifican que la implementación lo cumple.
Implementación robusta
Idempotencia, validación de entrada, límites de uso y errores claros desde la primera versión.
Publicación y ciclo de vida
Documentación accesible, versionado y un procedimiento para retirar versiones antiguas sin dejar a nadie atrás.
En Salamanca y alrededores
El soporte de las automatizaciones de tu empresa de Salamanca se presta en remoto, con alertas que avisan cuando algo falla.
Las empresas de Salamanca que dependen de un script en el ordenador de alguien suelen descubrirlo el día que ese ordenador falla; mejor antes.
Muchas empresas de Salamanca conviven con un programa antiguo que funciona; lo habitual es conectarlo y modernizar por partes, no tirarlo.
Ejemplos según tu actividad
Construcción
Conexión entre aplicaciones de obra, compras y contabilidad para que los partes y gastos lleguen sin teclearse dos veces.
Empresas con varias sedes
Integración de sistemas de distintas sedes con un modelo de datos común y responsables claros de cada dato.
Asesorías y despachos
Integración entre gestión documental, CRM y facturación para que un cliente se dé de alta una sola vez.
Educación
Automatización de matrículas, listados y comunicaciones, con cuentas de servicio para que no dependan del curso académico de nadie.
Criterios que importan
- Que proponga una primera versión pequeña antes que un proyecto enorme.
- Que distinga entre lo que se resuelve con una herramienta de flujos y lo que necesita código.
- Que hable de mantenimiento y su coste antes de firmar, no después.
- Que tenga una política para versionar y retirar APIs.
- Que tenga despliegue automatizado y forma de volver atrás.
Preguntas frecuentes
¿El código es mío?+
Sí. El repositorio está a tu nombre o se te entrega completo, con la documentación necesaria para que otro equipo pueda mantenerlo.
¿Qué mantenimiento necesita después?+
Actualizaciones de seguridad, revisión de dependencias, copias de seguridad y pequeños ajustes. Te proponemos un plan con lo que incluye y lo que no, para que sepas qué pagas.
¿Dónde se aloja la aplicación?+
Donde mejor te convenga: en nuestros servidores en Europa, en tu propia nube o en tu infraestructura. Lo decidimos según requisitos de datos, coste y quién va a operarla.
¿Hay que reescribir mi sistema heredado?+
Rara vez de golpe. Lo habitual es exponerlo mediante una API, ir sustituyendo módulos uno a uno y apagar lo antiguo cuando lo nuevo lleva tiempo funcionando.
¿Qué pasa si un servicio externo se cae?+
El diseño debe contemplarlo: límites de tiempo, reintentos con espera, cortacircuitos que dejan de insistir y colas que guardan el trabajo pendiente hasta que el servicio vuelva.
¿Cómo se actualizan dependencias antiguas sin romper nada?+
Primero se añaden pruebas que cubran lo crítico, luego se actualiza por partes y se verifica cada paso. Saltar varias versiones de golpe sin pruebas es la receta de un fin de semana largo.
Imputación de horas cerca de Salamanca
Para tu empresa en Salamanca
Envíanos tu idea, aunque esté a medio definir; el primer paso es ordenarla juntos.