Desarrollo web a medida para plataformas y aplicaciones

Un proyecto es de desarrollo a medida cuando tiene usuarios que entran con credenciales, permisos distintos según quién sea cada uno y reglas de negocio que no existen en ningún producto estándar.

Dos proyectos propios explican bien lo que hay detrás. Helix Trading es una plataforma de trading educativo con simulador propio, con el flujo completo de challenges, construida en Next.js y PostgreSQL y con autenticación separada por rol. DCL Hub Mobile App es una aplicación móvil de administración interna para gestionar los proyectos de DCL Hub sobre el terreno, en iOS y Android, y es un proyecto interno del estudio, no un encargo de cliente. Lo decimos porque conviene saber de quién es cada cosa.

También hay proyectos que empiezan siendo una migración. Consulting Staff era una consultoría de financiación europea sobre una base cerrada y pasó a una plataforma Next.js a medida, con CMS dedicado y seguimiento de proyectos. Cuando el negocio crece más rápido que la herramienta, ese es el camino habitual.

Y hay proyectos que no son esto. Si lo que necesitas es una web de presentación o una tienda con catálogo, cuesta bastante menos y va por otra vía: en la página de paquetes y precios tienes los tres niveles con su punto de partida.

La mitad del trabajo de una aplicación se hace antes de programar, y es la mitad que decide si el presupuesto se sostiene.

Quién entra y qué puede hacer. La lista de roles, escrita, con qué ve y qué puede cambiar cada uno. Un rol que aparece a mitad de proyecto toca la base de datos, la interfaz y los permisos a la vez.

El modelo de datos. Qué entidades existen, cómo se relacionan y qué campos son obligatorios. Cambiarlo después, con datos reales dentro, es de lo más caro que hay.

Qué queda registrado. Quién hizo qué y cuándo. En cualquier aplicación con varias personas dentro, el histórico deja de ser un lujo el primer día que dos versiones de la verdad no coinciden.

Qué pasa cuando algo falla. Si el sistema de facturación no responde, si la pasarela tarda, si el correo rebota. Las decisiones de error se toman antes, no cuando el error ocurre.

Qué entra en la primera versión. Preferimos una primera entrega corta que se use de verdad y crezca con lo aprendido, antes que un año de desarrollo contra un documento que nadie ha probado.

Todo esto acaba en un documento de alcance con criterios de aceptación: qué tiene que hacer la aplicación para que una entrega se dé por buena. Sobre ese documento se cierra el precio.

Al terminar, se te entrega todo y no se queda nada en nuestro lado.

El código, con acceso completo al repositorio y su historial. El servidor y el alojamiento a tu nombre, con las credenciales. Las cuentas de terceros creadas con tu correo como propietario, no con el nuestro. La documentación técnica: cómo se despliega, qué variables de entorno hay, cómo se restaura una copia de seguridad y qué hace cada integración.

Añadimos formación grabada para las personas que van a usar la aplicación y una sesión técnica para quien la vaya a mantener, seas tú, tu equipo o el proveedor que elijas.

Lo decimos con esta claridad porque existe la práctica contraria: software que solo funciona mientras pagas la cuota y que no se puede llevar a otro sitio. Nosotros no trabajamos así. Si un día cambias de proveedor, te vas con todo y sin discusión.

Casi ninguna aplicación vive sola. Se conecta con el programa de facturación, con el ERP, con el CRM, con la pasarela de pago, con el correo o con el almacén. Ahí es donde aparecen los problemas que no se ven en una maqueta.

Lo primero que miramos es qué ofrece el otro sistema: si tiene una interfaz de programación documentada, si permite exportaciones programadas o si solo hay ficheros. Eso cambia por completo el esfuerzo, y lo comprobamos antes de poner una cifra en el presupuesto.

Lo segundo es qué se hace cuando el otro lado no responde. Una integración seria no se limita a llamar y confiar. Se encolan las operaciones, se reintenta con espera creciente, se avisa a un responsable y queda registro de lo que falló, para poder reprocesarlo sin inventar datos a mano.

Lo tercero es la dirección de la información. Qué sistema manda sobre cada dato, para que no haya dos fuentes discutiendo sobre el mismo cliente o el mismo stock. Esa decisión se escribe en el documento de alcance.

Y lo cuarto, las credenciales. Claves guardadas fuera del código, con permisos mínimos y posibilidad de rotarlas sin parar la aplicación. Si alguien deja la empresa, se revoca su acceso sin tocar el desarrollo.

Dennis Media es un ejemplo pequeño y claro de esta forma de trabajar: un panel de administración a medida en Node.js con PM2, hecho para el día a día real de una agencia de vídeo y branding, no para el catálogo de funciones de un producto genérico.

Los proyectos a medida tienen precio cerrado tras el brief. El precio final depende del número de roles, de la cantidad de pantallas de gestión, de las integraciones y de si hay que migrar datos de un sistema anterior. Se cierra en el presupuesto, con el alcance escrito, y solo se mueve si pides algo nuevo y lo apruebas por escrito.

No publicamos un precio por hora en esta página. Presupuestamos por proyecto y por alcance cerrado, que es lo que te permite saber lo que vas a pagar antes de empezar. Si tu empresa necesita trabajar por bolsa de horas, pídelo en el correo y te lo respondemos por escrito.

Después del desarrollo hay un coste recurrente que conviene tener en la cabeza desde el principio, porque sorprende a mucha gente:

Lo desglosamos en el presupuesto para que veas qué pagas una vez y qué pagas cada mes. Una aplicación que nadie mantiene no se queda igual: envejece por el lado de la seguridad.

Hay tres piezas que separan un desarrollo profesional de uno que da sustos, y ninguna de las tres se ve desde fuera.

El entorno de pruebas. Una copia de la aplicación, separada de la que usan tus clientes, donde se revisa cada entrega antes de publicarla. Verificar en producción es la forma más rápida de aprender por qué no se verifica en producción.

Las copias de seguridad. Se hacen automáticas, con calendario, y se restauran de prueba cada cierto tiempo. Una copia que nunca se ha restaurado no es una copia, es una suposición. Nosotros comprobamos que se puede volver atrás de verdad.

El despliegue. Publicar una versión nueva tiene que ser un proceso repetible, con la posibilidad de volver a la versión anterior si algo sale mal. Se documenta, para que no dependa de que esté disponible una persona concreta un viernes por la tarde.

A eso le sumamos vigilancia del servicio, registro de errores y avisos cuando algo se cae. No prometemos que no vaya a fallar nada nunca, porque eso no lo puede sostener nadie. Lo que sí se puede es enterarse pronto, saber qué pasó por el registro y tener por dónde volver.

Con datos personales dentro hay una decisión más que se toma aquí: dónde se alojan las copias y cuánto tiempo se conservan. Se escribe en la documentación y se revisa con quien lleve la protección de datos en tu empresa.

Un proyecto a medida no se entrega una vez al final. Se entrega por partes, y cada parte se prueba.

Trabajamos por bloques cortos con una entrega visible al terminar cada uno. En la revisión ves la aplicación funcionando en el entorno de pruebas, no capturas de pantalla, y decides si eso es lo acordado. Lo que se habla en la llamada se resume por escrito y se envía el mismo día, para que las decisiones no dependan de la memoria de nadie.

Tienes una persona de contacto durante todo el proyecto y es alguien que trabaja en tu aplicación, no un intermediario. Respondemos los correos en 24 horas laborables.

Entre la España peninsular y Rumanía hay una hora de diferencia, dos si estás en Canarias. Las jornadas se solapan casi enteras, así que las reuniones se ponen a la hora que te venga bien a ti. No tenemos oficina en España y no decimos lo contrario: si tu proyecto necesita a alguien presencial, te lo diremos en el primer correo.

Páginas relacionadas: webs corporativas a medida