Desarrollo de software
Imputación de horas en Andújar
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.
Muchas automatizaciones entre aplicaciones se resuelven con un orquestador de flujos como n8n en lugar de código a medida. Es más rápido de montar y de cambiar, siempre que se trate con el mismo rigor: control de versiones, credenciales separadas y monitorización.
Desplegar no debería dar miedo. Con despliegues automatizados, entornos de prueba y activación gradual de funciones, una versión nueva se puede publicar un martes por la mañana y retirar en minutos si algo falla.
Situaciones que resolvemos
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.
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.
Decisiones técnicas sin explicar
El sistema tiene elecciones extrañas que nadie recuerda por qué se tomaron, y da miedo cambiarlas.
Despliegues manuales y arriesgados
Publicar una versión depende de una persona y de una lista de pasos que no está escrita. Si esa persona no está, no se publica.
Cambios que rompen cosas lejanas
Se toca una función y falla otra que nadie relacionaba. No hay pruebas que lo detecten antes de publicar.
El camino, paso a paso
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.
¿Hablamos de tu caso?
Si dudas entre app y web, te ayudamos a decidir según cómo la usarán tus clientes.
Qué te llevas al terminar
- Políticas DLP por entorno que definen qué conectores pueden combinarse, revisadas antes de activarse.
- Patrón de publicación fiable de eventos (outbox transaccional) donde una operación y su aviso deben ir juntos.
- Pruebas automáticas de las funciones críticas que se ejecutan antes de cada publicación.
- Robots o flujos automatizados con cuentas de servicio, registro de ejecución y alertas cuando fallan.
- Medición de rendimiento con Core Web Vitals en las páginas clave y un presupuesto de rendimiento acordado.
- Modelo de entornos de Power Platform (desarrollo, pruebas, producción) con permisos por rol.
- Pruebas automáticas de las funciones críticas integradas en el ciclo de entrega.
Por sectores
- Industria
- Aplicaciones de planta para partes de trabajo, control de calidad u órdenes de fabricación, pensadas para tabletas y uso con guantes o prisa.
- Inmobiliarias
- Webs con fichas de inmuebles alimentadas desde el CRM, formularios de interés bien cualificados y áreas privadas para propietarios.
- Educación y formación
- Plataformas de inscripción, gestión de grupos y comunicación con alumnos y familias, con control de accesos por perfil.
- Construcción
- Conexión entre aplicaciones de obra, compras y contabilidad para que los partes y gastos lleguen sin teclearse dos veces.
Automatizado de principio a fin
Lo que montamos queda documentado y se puede repetir, no depende de una persona.
$ desplegar tuempresa
✓Versión de la aplicación verificada
✓Base de datos creada
✓Aplicación arrancada y sana
✓Primer administrador creado
✓Dominio configurado
✓Certificado TLS emitido
Listo: https://tuempresa.forgenex.com
Qué mirar antes de elegir
- Que opere sistemas propios en producción y pueda hablar de incidentes reales.
- Que separe entorno de pruebas y producción y te deje revisar cada entrega.
- Que pregunte si hay API antes de proponer un robot que lea pantallas.
- Que defina qué sistema es dueño de cada dato.
- Que te enseñe software suyo en producción, no solo capturas de pantalla.
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 completaIngeniería de software
Checklist ALM para Microsoft Power Platform en empresas
Flujo recomendado
No promociones una solución solo porque “funciona en mi entorno”. Comprueba que los conectores y referencias apuntan a los recursos correctos y que el despliegue conserva las políticas de datos. Las pipelines de Power Platform, la guía de ALM y la documentación de políticas de datos detallan las capacidades del…
Leer la guía completaDesarrollo y arquitectura
Arquitectura de Microservicios con Spring Boot y Docker Swarm
Orquestación con Docker Swarm
Mientras que el código de Spring Boot maneja la lógica de negocio y el enrutamiento a nivel de aplicación, Docker Swarm gestionará el ciclo de vida del contenedor, el escalado horizontal y la resolución DNS interna a nivel de red (Overlay Network).
Leer la guía completaTrabajar con empresas de Andújar
Para equipos de desarrollo de Andalucía, proponemos prácticas de ingeniería proporcionadas: lo justo para dejar de depender de la suerte.
Cuando la integración afecta a equipos físicos de una planta en Jaén, se puede organizar una visita puntual si el proyecto lo requiere.
Muchas empresas de Jaén conviven con un programa antiguo que funciona; lo habitual es conectarlo y modernizar por partes, no tirarlo.
Preguntas frecuentes
¿Qué pasa si una versión nueva da problemas?+
El despliegue está preparado para volver a la versión anterior rápidamente, y las funciones nuevas pueden activarse de forma gradual para detectar fallos con pocos usuarios.
¿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.
¿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.
¿RPA, low-code o integración por API?+
Si el sistema tiene API, casi siempre es la opción más estable. El low-code va bien para flujos entre aplicaciones conocidas. El RPA queda para cuando no hay otra forma de acceder, sabiendo que es lo más frágil ante cambios de pantalla.
¿Podéis revisar una arquitectura que ya tenemos?+
Sí. Hacemos una revisión con un informe de riesgos, puntos de mejora priorizados y lo que no recomendamos tocar.
¿Cuándo conviene usar eventos en lugar de llamadas directas?+
Cuando varios sistemas necesitan enterarse de lo mismo, cuando no quieres que uno dependa de que otro esté disponible o cuando los datos deben llegar casi al momento. Para consultas simples, una llamada directa basta.
Imputación de horas cerca de Andújar
Cuéntanos qué proceso llevas hoy en hojas de cálculo y te decimos cómo sería una primera versión.