Decidir si hay que construir
Una parte de nuestro trabajo es decirle que no lo construya. Si un producto estándar cubre el 80 %, adaptarse a él casi siempre sale mejor que mantener código propio durante años.
Primero miramos si ya existe algo que lo resuelva, porque casi siempre existe y sale más barato. Cuando no, construimos: con código suyo, documentado y sin dependencias que no pueda mantener.
Una parte de nuestro trabajo es decirle que no lo construya. Si un producto estándar cubre el 80 %, adaptarse a él casi siempre sale mejor que mantener código propio durante años.
Portales de cliente, herramientas internas, plataformas SaaS. Con autenticación de verdad, permisos por rol y pensadas para que las use gente que no es técnica.
Lo que conecta su sistema con los demás: pasarelas, facturación electrónica, ERP, CRM. Con contrato de API documentado, versionado y control de errores que no se traga los fallos.
Captura en campo, funcionamiento sin cobertura, sincronización al volver la señal. Antes de una app nativa comprobamos si una web instalable resuelve lo mismo por la mitad.
Pruebas, despliegue automatizado, registro de errores y documentación. Un sistema sin eso funciona el primer día y da problemas todos los demás.
Todo lo que verá abajo lo usamos en proyectos reales. Si algo no está en la lista, se lo decimos antes de empezar y no después.
Las dos cosas, y conviene mirar primero lo hecho. Tenemos siete plataformas propias, seis en producción y una en camino: THOMAS para seguridad y salud en el trabajo, LUCY para clínicas veterinarias, RONALD para alquiler de vehículos, EDITH para obra y contratistas, Arqueo para contabilidad y facturación en cualquier sector, PILI para centros de terapia y rehabilitación y KEYLOR, el sistema de información hospitalaria para clínicas y centros médicos. Si su caso encaja en una de ellas, arranca en semanas y cuesta una fracción de lo que cuesta construir. Si no encaja, se hace a medida y se lo decimos sin rodeos: vender un producto que no resuelve el problema nos cuesta el cliente en el mes tres.
Sí, y es lo más barato que puede pasarle. Los construimos nosotros, así que el roadmap lo movemos en vez de pedirlo a un tercero. Ahora bien, no todo se adapta: cuando lo que pide cambia el modelo de datos por debajo, adaptarlo sale más caro que partir de cero, y en ese caso también se lo decimos.
Suyo, desde el primer commit, en su repositorio. Entregamos código, documentación técnica y accesos. No usamos licencias que le aten a nosotros ni dejamos partes cerradas.
Calcule entre un 15 y un 20 % anual del coste de construcción, entre actualizaciones de dependencias, cambios pequeños y correcciones. Quien no le dé esa cifra al cotizar, se la va a cobrar igual más adelante.
Sí, interfaz y experiencia incluidas. No somos un estudio de marca: si necesita identidad corporativa completa, trabajamos con su diseñador o le recomendamos uno.
Sí, y es más común de lo que parece. Empezamos por una revisión del código y le decimos con franqueza qué se puede aprovechar y qué sale más barato rehacer. A veces la respuesta incomoda.
Entregamos por bloques que funcionan, con demostración cada dos semanas y prioridades revisables. Lo que no hacemos es usar «ágil» como excusa para no comprometer alcance ni fecha.
Veinte minutos bastan para saber si hay proyecto. Si no lo hay, se lo decimos de frente.