Software a medida

Arquitectura de software con svelte

Hacemos nuestros propios productos —CRM, facturación, fichaje, gestión de tareas— con el mismo método con el que trabajamos para clientes. Lo que te proponemos lo hemos puesto antes en producción nosotros.

Ningún proceso de ingeniería sustituye al criterio, pero sí evita depender de la suerte. Revisiones, pruebas y despliegues automatizados convierten los errores en algo que se detecta pronto y se corrige barato.

Trabajamos con contenedores Docker y, cuando la escala lo pide, con Kubernetes. Pero el objetivo no es la herramienta, sino que desplegar, escalar y recuperar el sistema sea un procedimiento repetible y no un arte.

Pide una propuesta Prueba el CRM sin tarjeta

Desplegado como desplegamos lo nuestro

Cada paso automatizado y comprobado, con su copia y su certificado.

forgenex

$ 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

Por qué nos llaman

01
Sistemas que no se hablan
El CRM, la facturación y el almacén no comparten datos y alguien los copia de uno a otro. Los errores aparecen cuando el cliente ya los ha visto.
02
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.
03
Scripts sueltos en el ordenador de alguien
Procesos importantes dependen de scripts sin control de versiones, sin registro y sin nadie que sepa qué hacen exactamente.
04
Requisitos que cambian en mitad del desarrollo
No hay criterios de aceptación escritos, cada parte entiende algo distinto y las entregas se discuten en lugar de comprobarse.
05
Decisiones técnicas sin explicar
El sistema tiene elecciones extrañas que nadie recuerda por qué se tomaron, y da miedo cambiarlas.

Qué recibes

Aplicación o web desplegada en producción con entorno de pruebas separado.
Plan de mantenimiento con actualizaciones de seguridad y revisión periódica de dependencias.
Pruebas de carga sobre los puntos críticos y un informe de límites conocidos.
Integraciones con tus sistemas existentes mediante API, documentadas.
Pruebas automáticas de las funciones críticas integradas en el ciclo de entrega.
Política de versionado y retirada de APIs con avisos a los consumidores.
Integraciones entre sistemas con reintentos, idempotencia y gestión de errores documentada.

¿Hablamos de tu caso?

Si tienes una aplicación heredada sin documentación, empecemos por una auditoría para saber en qué punto está.

Pide tu propuesta

Lecturas relacionadas

Desarrollo 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 completa

Desarrollo y arquitectura

Patrón transactional outbox en arquitecturas de empresa

Diseña para duplicados y fallos

La entrega puede repetirse, por ejemplo si el publicador envía el mensaje y falla antes de marcarlo como procesado. Por eso el consumidor debe ser idempotente: registrar el ID tratado, rechazar efectos duplicados o aplicar una operación segura ante repetición.

Leer la guía completa

Desarrollo

Plantilla ADR para decisiones de arquitectura de software

Guarda el razonamiento que no cabe en un diagrama

Una decisión de arquitectura puede ser costosa de cambiar y difícil de reconstruir meses después. Un ADR (Architecture Decision Record) conserva el contexto, las alternativas consideradas y las consecuencias que el equipo acepta. Conviene escribirlo cuando una elección afecta a límites del sistema, datos, despliegue,…

Leer la guía completa

El camino, paso a paso

Inventario

Localizamos todas las automatizaciones y aplicaciones low-code, con quién las creó, qué hacen y qué datos tocan.

Clasificación por riesgo

Ordenamos por impacto si fallan y sensibilidad de los datos, para saber por dónde empezar.

Marco de gobierno

Entornos, políticas de conectores, cuentas de servicio y un camino claro de desarrollo a producción.

Migración ordenada

Pasamos las automatizaciones críticas al nuevo marco una a una, comprobando que siguen funcionando.

Operación continua

Revisión periódica del inventario, alertas de fallos y acompañamiento a quien crea nuevas soluciones.

Ejemplos según tu actividad

Servicios técnicos: Aplicaciones para técnicos de campo con órdenes de trabajo, material usado y firma del cliente, sincronizadas con la oficina.
Departamentos financieros: Automatización de conciliaciones y cargas contables con registro de cada ejecución y validación del responsable.
Clínicas (gestión administrativa): Webs, citas y facturación sin tratar historia clínica ni datos de salud, que quedan en los sistemas sanitarios especializados.
Construcción: Gestión de obras con partes diarios, fotos geolocalizadas, mediciones y control de documentación de subcontratas.

Preguntas que deberías hacer a cualquier proveedor

Que mida cuánto resuelve sola cada automatización y cuánto escala a personas.
Que use en sus propios productos las prácticas que te propone.
Que proponga una primera versión pequeña antes que un proyecto enorme.
Que tenga una política para versionar y retirar APIs.
Que proponga modernizar por fases antes que reescribir de golpe.

Preguntas frecuentes

¿Puede integrarse con mi programa de gestión?+

Si tu programa tiene API o permite intercambiar datos de forma estable, sí. Si no, buscamos la forma menos frágil y te explicamos sus límites.

¿Podéis seguir con un proyecto que empezó otro proveedor?+

Sí, tras revisarlo. Te diremos con franqueza en qué estado está, qué riesgos tiene y si compensa continuar o rehacer partes.

¿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 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.

¿Podéis ordenar lo que ya tenemos sin empezar de cero?+

Sí, es lo habitual. Inventariamos, priorizamos por riesgo y migramos lo importante a un marco ordenado, dejando lo que funciona como está.

¿Esto tiene sentido para una empresa pequeña?+

A escala reducida, sí. Un repositorio, unas pocas pruebas de lo crítico y un despliegue automatizado ya evitan la mayoría de sustos. No hace falta el proceso de una gran empresa.