Aplicaciones web
- Mis servicios de desarrollo de aplicaciones web
- ¿Cuándo pasar al desarrollo personalizado?
- Tipos de proyectos
- Características
- Arquitectura de software
- Tecnologías
- El presupuesto
- El mantenimiento
- Etapas del proyecto
1. Mis servicios de desarrollo de aplicaciones web:
Desarrollo su aplicación web, ya sea parcial o totalmente. Es mi especialidad y lo que más disfruto. Mi amplia experiencia en
todo tipo de proyectos (startups, bootstraping y grandes empresas) me proporciona una visión global para elegir las tecnologías,
y para optimizar el desarrollo, los costes y el mantenimiento según las necesidades.
También doy gran importancia a las buenas prácticas de desarrollo,
especialmente en términos de seguridad, rendimiento y estructuración del código.
Más que un desarrollo externalizado, apoyo a mis clientes a construir juntos una
aplicación exitosa.
Tipos de desarrollo: - Desarrollo de un MVP (Producto Mínimo Viable)
- Desarrollo de nuevas características
- Mantenimiento de una aplicación existente
- Refactorización de una aplicación existente
- Integración API
Consejo: A la hora de desarrollar una nueva aplicación, se recomienda comenzar con el desarrollo más
sencillo posible, conocido como MVP, siguiendo la metodología ágil/lean.
Definición: En desarrollo de producto, el producto viable mínimo (MVP, del inglés Minimum Viable
Product) es un producto con suficientes
características para satisfacer a los clientes iniciales, y proporcionar retroalimentación para el desarrollo futuro.
Un MVP también significa vendible: "no es un MVP hasta que lo vendes. Viable significa que puedes tener clientes
con tu producto y ganar dinero".
2. ¿Cuándo pasar al desarrollo personalizado?
Una pregunta frecuente es cuándo pasar al desarrollo personalizado. Analicemos los diferentes escenarios:
2.1 Precaución
Si no está familiarizado con la industria del desarrollo de software, no es recomendable comenzar un
proyecto complejo desde cero si no cuenta con un equipo de TI interno.
Un error común es contratar una agencia de desarrollo al inicio de un proyecto, proporcionando especificaciones demasiado ambiciosas desde el principio.
Sin duda, es motivador querer ofrecer al mercado una nueva aplicación con numerosas funciones que superará a la
competencia. Sin embargo, si no dispones de un presupuesto importante (IT y marketing), rápidamente te verás atrapado en lo que se
llama deuda técnica por un lado, y en la subestimación casi sistemática del coste de mantenimiento por otro,
y todo esto sin tener en cuenta la idoneidad para el mercado objetivo, que nunca está garantizado.
Definición: La deuda técnica (o technical debt en inglés) se refiere a todos los compromisos
técnicos realizados a corto plazo en el desarrollo de software para ahorrar tiempo, pero que tienen
un costo a largo plazo en complejidad, mantenimiento, rendimiento o calidad del código.
Esto funciona por ahora, pero ralentizará futuros desarrollos y aumentará el riesgo de errores. Tipos de deuda técnica :
- Deliberado: elección asumida (p. ej.: “codificamos rápidamente ahora, refactorizamos después”).
- Accidental: causado por ignorancia, inexperiencia o mala comunicación.
- Obsolescencia: el código se convierte en deuda porque el framework o la técnica utilizada envejece.
- Estructural: la arquitectura o el diseño no se adapta a la evolución del proyecto.
2.2 En el caso de un proyecto sencillo y altamente personalizado
El desarrollo personalizado para un proyecto simple es relevante cuando se desea :
- Un sitio ligero, rápido y sin dependencias.
- Mayor seguridad.
- Control completo del código.
- Un presupuesto de mantenimiento prácticamente nulo.
2.3 Después de WordPress
El cambio a lo personalizado es relevante cuando :
- WordPress te obstaculiza más de lo que te ayuda (limitaciones técnicas, problemas de escalabilidad, mantenibilidad y deuda técnica, etc.).
- Quiere diferenciarse fuertemente de la competencia con una plataforma innovadora.
- Necesita una solución estable, escalable y controlada internamente con una UX/UI muy específica.
- Su sitio web se convierte en una aplicación empresarial o en una palanca estratégica para el crecimiento.
2.4 Después de no-code
- Ha validado su mercado con una plataforma no-code y está buscando pasar al siguiente paso.
- Para funciones no estratégicas, utilizar el no-code es más que suficiente.
- Por otro lado, si tu valor añadido depende en gran medida de tu plataforma, es recomendable
ser independiente con un desarrollo personalizado.
2.5 Para refactorizar
- El proyecto ya existe, pero debido a una tecnología obsoleta o a modificaciones y añadidos
constantes, su estructura se ha vuelto inmanejable.
- En este caso, tiene sentido refactorizar todo o parte del proyecto.
- Las tecnologías propuestas son totalmente apropiadas.
2.6 Proyecto a medida con pleno conocimiento de causa
- No se recomienda empezar desde cero un proyecto complejo.
- Pero si sabes exactamente lo que quieres y ya has gestionado un proyecto
de TI, entonces sí, el desarrollo personalizado ofrece muchas ventajas.
5. Arquitectura de software