Servicio
Desarrollo de aplicaciones web a medida
Plataformas que aguantan carga real, datos reales y usuarios reales.
La web es donde vive la mayor parte de lo que construimos: plataformas internas que hacen funcionar un negocio, portales de cliente, paneles sobre datos de operación reales y sitios públicos que deben ser rápidos y encontrables. Construidos como aplicaciones en lugar de ensamblados a partir de extensiones, que es precisamente lo que hace que sigan siendo modificables un año después.
La decisión
Cuándo es la elección correcta.
La decisión rara vez enfrenta lo hecho a medida con la nada. Enfrenta lo hecho a medida con una plataforma más las extensiones necesarias para cerrar la distancia entre lo que hace y lo que usted necesita. Ese apilamiento es barato de empezar y caro de tener: cada extensión es una dependencia, un coste de rendimiento y una superficie de ataque, y el conjunto se rompe en la próxima versión mayor de la plataforma.
El segundo coste es el techo. Los proyectos sobre plataforma avanzan rápido hasta el primer requisito que la plataforma no puede expresar, y entonces el apaño se convierte en la arquitectura. Las empresas acaban reorganizándose en torno a su software en lugar de lo contrario, que es exactamente la situación que comprar el software debía evitar.
Lo hecho a medida vale su coste cuando la lógica de negocio es el producto, cuando el modelo de datos es realmente suyo, o cuando el rendimiento y la integración importan lo bastante como para ser decisiones de ingeniería. Cuando nada de eso es cierto, lo decimos: una plataforma bien elegida es mejor respuesta que un proyecto que nosotros habríamos disfrutado más.
Lo que se obtiene
Qué cubre el encargo.
Una arquitectura que aguanta el crecimiento
Modelo de datos, fronteras y despliegue decididos antes de la primera pantalla, porque son las decisiones cuya marcha atrás sale cara.
Renderizado en servidor donde importa
Páginas que un rastreador y un teléfono lento reciben completas, con la interactividad añadida encima en vez de condicionar la aparición del contenido.
Autorización real
Los permisos se aplican en el servidor en cada petición, no ocultando entradas de menú. Y se comprueban con pruebas que intentan saltárselos.
El rendimiento como presupuesto con cifra
Los Core Web Vitals se tratan como una restricción de compilación con cifra, y no como un informe lanzado tras la puesta en marcha.
Accesibilidad incorporada desde el inicio
Recorrido por teclado, gestión del foco, contraste y semántica desde el primer componente, lo que cuesta menos que corregirlo después y además favorece el posicionamiento.
Operable en producción
Registro, notificación de errores, copias de seguridad y restauración ensayada, porque un software que no se puede operar no está terminado.
Stack
Con qué lo construimos.
Elegidos proyecto a proyecto. Aquí no se impone nada por defecto, y el equipo que se encargará del mantenimiento pesa tanto como el problema.
Frontend
TypeScript con React o plantillas renderizadas en servidor, elegido proyecto a proyecto. Ningún framework se impone por defecto.
Backend
Python, Node o .NET, elegidos tanto en función del equipo que los mantendrá como del problema.
Datos
PostgreSQL o MySQL, con un esquema diseñado y no generado. Redis donde la caché realmente ayuda.
Infraestructura
Linux, nginx, en contenedores donde compensa la complejidad: en su nube o en la nuestra.
Entrega
Control de versiones, pruebas automatizadas y cadena de despliegue desde el primer día, no añadidos cuando ya duele.
Comparación
Construcción sobre plataforma frente a desarrollo a medida.
La comparación que hay que hacer antes de encargar nada. En una buena parte de los proyectos gana la columna de la izquierda, y lo diremos.
| Aspecto | Plataforma + extensiones | Desarrollo a medida |
|---|---|---|
| Plazo hasta tener algo utilizable | Unos días. Es una ventaja real, y a menudo decisiva. | Semanas. Se justifica solo cuando la plataforma no puede expresar lo que usted necesita. |
| Estructura del coste | Bajo y recurrente: licencia, crecimiento por usuario, suscripción por extensión, socio integrador | Alto y puntual, y luego el alojamiento. El código es suyo, sin licencia de ejecución. |
| El techo | Se alcanza con el primer requisito que la plataforma no puede expresar; a partir de ahí el apaño es la arquitectura | Fijado por sus propias decisiones de diseño, no por la hoja de ruta de un tercero |
| Superficie de dependencias | Cada extensión es código que usted no escribió, con su propio ciclo de publicación, dentro de su perímetro de seguridad | Solo las bibliotecas que usted eligió, revisadas y fijadas |
| Actualizaciones de versión mayor | Lo que se rompe es la combinación de extensiones, y se rompe según el calendario de otro | Usted decide cuándo, y las pruebas le dicen qué se ha movido |
| Rendimiento y Core Web Vitals | El peso del tema y las extensiones, resuelto añadiendo una extensión de caché | Una restricción de compilación con una cifra, aplicada en el pipeline |
Cómo se desarrolla
De la primera conversación a estar en producción.
Orientativo para un trabajo de esta naturaleza. El piloto no es opcional: nada se conmuta hasta que los usuarios dicen que aguanta.
- 1 a 2 semanas
Definición del alcance
Modelamos primero los datos y los roles. Ahí está realmente el coste, y ahí es donde los proyectos sobre plataforma descarrilan con más frecuencia, no en las pantallas.
- 4 a 8 semanas
Construcción de los cimientos
La ruta más transitada de extremo a extremo, con sus datos reales y una cadena de despliegue desde la primera semana, no cuando ya duele.
- 2 a 3 semanas
Piloto
Un equipo lo usa para trabajo real mientras el proceso antiguo continúa. Cada carencia que encuentra se corrige antes de que cambie nadie más.
- 1 a 2 semanas
Puesta en marcha y traspaso
Los usuarios restantes, la supervisión y copias de seguridad con restauración ensayada, con la documentación que permite a otro desarrollador continuar.
Después de la puesta en marcha
Qué cambia.
- El requisito que la plataforma no podía expresar deja de resolverlo una persona en una hoja de cálculo.
- El rendimiento de las páginas pasa a ser una cifra que usted sostiene, y no una extensión que espera que actúe.
- Las actualizaciones mayores dejan de ser un acontecimiento, porque no hay combinación de extensiones que romper.
- Un cambio que se quiere en la semana sesenta cuesta aproximadamente lo que habría costado en la semana seis.
Descrito cualitativamente a propósito. No publicamos porcentajes de mejora que no podamos vincular a un cliente concreto con su consentimiento.
Preguntas
Preguntas frecuentes.
¿Cuánto tarda una aplicación web a medida?
Una plataforma interna acotada suele llevar de ocho a catorce semanas desde la primera conversación hasta producción. Los sistemas mayores y multimódulo llevan más tiempo y se entregan por fases, con el primer módulo en producción mientras se construye el siguiente: preferimos que usted use algo real pronto a que espere al conjunto.
¿El código es nuestro?
Sí, por completo, incluidos el repositorio y la configuración de despliegue. No hay licencia de ejecución ni nada que impida a otro desarrollador continuar.
¿Podéis trabajar con nuestro sistema existente?
Normalmente sí. La mayoría de los proyectos empiezan integrándose con algo que ya existe: un programa de contabilidad, un ERP, una base de datos antigua. Sustituirlo todo de golpe rara vez es lo correcto, y un camino por fases es más seguro.
¿Qué ocurre después del lanzamiento?
Se incluye un periodo de soporte y, después, la mayoría de los clientes contrata una cuota de mantenimiento para cambios y monitorización. Ninguna de las dos cosas te ata: el código es tuyo y está documentado lo bastante bien como para que lo retome otra persona.
¿No deberíamos simplemente comprar una plataforma?
A menudo, sí. Si su modelo de datos encaja en la plataforma y el software no es lo que le diferencia, la plataforma es más rápida y más barata y se lo diremos. Lo hecho a medida se gana su sitio cuando la lógica de negocio es el producto, cuando el modelo de datos es realmente suyo, o cuando la integración y el rendimiento son problemas de ingeniería y no ajustes.
¿Qué pasa si nuestros requisitos cambian a mitad de camino?
Cambiarán, y el plan lo da por supuesto. Las fases se vuelven a estimar en cada hito con lo aprendido, y por eso preferimos un precio con tope por fase a un precio cerrado para todo el alcance: este último o está inflado por el riesgo o acaba en disputa al primer cambio.