Desarrollo de software
Software a medida en Reus
Preferimos entregar algo pequeño que funciona a las pocas semanas antes que un proyecto enorme que llega tarde. Cada entrega se usa de verdad, se corrige con lo aprendido y se decide qué va después.
Software a medida parte de una pregunta sencilla: qué tiene que seguir funcionando cuando una pieza falla. A partir de ahí se decide dónde poner reintentos, colas, límites de tiempo y qué hacer cuando un servicio externo no contesta.
Cuando un sistema necesita enterarse de lo que pasa en otro casi al momento, los eventos funcionan mejor que preguntar cada pocos minutos. Usamos colas y captura de cambios de base de datos (CDC) cuando el caso lo justifica, no por defecto.
Por qué nos llaman
Datos personales mal custodiados
Formularios, portales y bases de datos guardan información de clientes sin control de accesos claro ni copias, y eso es un riesgo legal además de técnico.
Crecimiento que el sistema no aguanta
Lo que funcionaba con pocos usuarios se vuelve lento con el doble. Las páginas tardan, los informes se cuelgan y el equipo pierde tiempo esperando.
Integraciones que fallan al desplegar
Dos equipos o proveedores cambian sus APIs por separado y la incompatibilidad se descubre en producción.
Todo se prueba en producción
No hay entorno de pruebas o no se parece al real, así que los cambios se validan directamente con datos de clientes.
Aplicaciones Power Platform sin control
Varios departamentos han creado aplicaciones y flujos por su cuenta. Nadie sabe cuántos hay, quién los mantiene ni qué datos manejan.
Y cuando toca facturar
El trabajo hecho se factura sin copiar datos, y el cobro vuelve a la ficha del cliente.
Nuestro método
Auditoría de lo que existe
Revisamos la aplicación o web actual: código, dependencias, rendimiento, accesibilidad y seguridad.
Estabilizar
Primero lo urgente: copias de seguridad, actualizaciones críticas y un despliegue repetible.
Rodear y sustituir por partes
Exponemos el sistema actual mediante una API y vamos sustituyendo módulos uno a uno sin parar la operación.
Retirar lo antiguo
Cuando un módulo nuevo lleva tiempo funcionando, se apaga el viejo y se archivan sus datos.
¿Hablamos de tu caso?
Cuéntanos qué proceso llevas hoy en hojas de cálculo y te decimos cómo sería una primera versión.
El resultado, en concreto
- Plan de modernización por fases para sistemas heredados, sin parar la operación.
- Canal de integración y despliegue continuo con pruebas automáticas y vuelta atrás.
- Despliegue automatizado: cada versión se construye, se prueba y se publica con el mismo procedimiento, y se puede revertir.
- Criterios de aceptación escritos y comprobables para cada funcionalidad.
- Copias de seguridad de la base de datos configuradas y una restauración probada.
- Robots o flujos automatizados con cuentas de servicio, registro de ejecución y alertas cuando fallan.
- Documentación de operación: cómo desplegar, escalar, recuperar y diagnosticar.
Cómo elegir bien
- Que pregunte si hay API antes de proponer un robot que lea pantallas.
- Que reconozca los límites de cada herramienta, incluidas las que vende.
- Que te enseñe software suyo en producción, no solo capturas de pantalla.
- Que use en sus propios productos las prácticas que te propone.
- Que trate los datos personales con control de accesos, copias y registro desde el diseño.
Profundiza en el tema
Ingeniería de software
Power Platform: gobierno de políticas DLP por entorno
Patrón de diseño por entorno
Entorno Enfoque de política Validación antes de ampliar --- --- --- Desarrollo personal o de equipo Conectores y datos de prueba; permisos limitados y reglas que eviten mezclar datos corporativos con servicios no aprobados. Probar creación de apps y flujos representativos. Pruebas Conectores necesarios para…
Leer la guía completaDesarrollo y arquitectura
CI/CD con GitLab Runners y Kubernetes
Estructuración del Pipeline (.gitlab-ci.yml)
Con el Runner operando en K8s, cada job definido en el .gitlab-ci.yml se ejecutará en un contenedor aislado. Para exprimir al máximo esta arquitectura, emplearemos el patrón Docker-in-Docker (DinD) para compilar y pushear imágenes de contenedores desde dentro de Kubernetes, o herramientas daemonless como Kaniko.
Leer la guía completaDesarrollo y arquitectura
Idempotencia en APIs y webhooks: reintentos sin duplicados
El timeout no indica si la operación se ejecutó
Un cliente envía una solicitud para crear un pedido. El servidor la procesa, pero la respuesta se pierde. Si el cliente repite la llamada sin protección, puede crear un segundo pedido. La API necesita reconocer que la segunda petición pertenece a la misma operación lógica.
Leer la guía completaNo es igual en todos los negocios
Educación
Integración entre plataformas de inscripción, cobro y aula virtual, con un único origen de datos de alumnos.
Comercio electrónico
Arquitectura que aguanta picos de campaña con colas para los procesos pesados y caché para lo que más se consulta.
Despachos profesionales
Flujos de alta de expedientes, archivo de documentos y recordatorios, gobernados para que la información confidencial no salga de donde debe.
Hostelería y turismo
Sincronización de disponibilidad y reservas entre canales, donde un retraso o un duplicado provoca sobreventas.
En Reus y alrededores
Para equipos de desarrollo de Cataluña, proponemos prácticas de ingeniería proporcionadas: lo justo para dejar de depender de la suerte.
En muchas pymes de Tarragona, las tareas de copiar datos entre programas se llevan horas cada semana; es el primer sitio donde mirar.
Si tu empresa de Reus ya tiene personas creando aplicaciones low-code, el objetivo es darles un marco, no quitarles la herramienta.
Preguntas frecuentes
¿Tengo que dedicar tiempo de mi equipo?+
Sí, algo. Necesitamos a alguien que conozca el proceso para validar prototipos y entregas. Sin esa participación, el software acaba resolviendo un problema que no es el tuyo.
¿Cómo se prueba antes de publicar?+
Hay un entorno de pruebas separado, pruebas automáticas de lo crítico y revisión por tu parte de cada entrega antes de pasar a producción.
¿Cuánto tiempo hasta tener algo funcionando?+
Buscamos que haya una primera versión usable cuanto antes, aunque sea limitada. El plazo concreto depende del alcance y lo acordamos al cerrar el documento de alcance.
¿Qué es una API contract-first?+
Es acordar la interfaz por escrito, en OpenAPI, antes de programarla. Quien la consume y quien la implementa trabajan sobre el mismo documento y los malentendidos aparecen antes de escribir código.
¿Cómo sé si una automatización funciona bien?+
Con su registro y un panel de estado: cuántas ejecuciones han ido bien, cuántas han fallado y cuántas han necesitado intervención humana.
¿Qué es un SBOM y para qué sirve?+
Es un inventario de los componentes y versiones que forman cada entrega de software. Sirve para saber rápidamente si te afecta una vulnerabilidad publicada. No es una auditoría de seguridad: dice qué hay, no si es seguro.
Software a medida cerca de Reus
Para tu empresa en Reus
Escríbenos con lo que necesitas y te devolvemos una propuesta de alcance para la primera entrega.