CodeIgniter 4 vs Laravel: por qué elegimos CI4 para proyectos de cliente y cuándo no lo hacemos

Cuando alguien pregunta qué framework PHP usar, la respuesta fácil es Laravel. Más tutoriales, más paquetes, más ofertas de trabajo en LinkedIn. Si buscas visibilidad como desarrollador o necesitas contratar en el mercado generalista, Laravel gana la comparativa de popularidad sin discusión.

Pero en Flexum llevamos años trabajando en proyectos de cliente reales —portales de gestión, intranets, APIs para apps móviles, paneles para equipos de 3 a 15 personas— y para la mayoría de esos proyectos elegimos CodeIgniter 4. No porque Laravel sea malo, sino porque las comparativas técnicas habituales ignoran lo que realmente importa cuando alguien más tiene que mantener el código en dos años.

Este artículo explica cómo tomamos esa decisión, qué factores pesan de verdad, y cuándo elegimos Laravel sin dudarlo.

Lo que las comparativas técnicas no te cuentan

Las comparativas entre frameworks suelen medir líneas de código por función, benchmarks de peticiones por segundo en condiciones de laboratorio, número de paquetes disponibles en Packagist, y tamaño de la comunidad medido en estrellas de GitHub.

Nada de eso te dice lo que pasa cuando un proyecto cambia de manos dieciocho meses después de la entrega. Nada te dice qué pasa cuando el desarrollador que lo construyó ya no está disponible y alguien nuevo tiene que añadir un módulo de facturación. Nada mide el tiempo que tarda un programador PHP con experiencia media en entender qué hace un trozo de código.

Más features no significa mejor para mantenimiento. Significa más superficie que entender, más convenciones que respetar, más magia que trazar cuando algo falla. Laravel es un framework extraordinariamente completo, pero esa completitud tiene un coste de comprensión que se paga cada vez que alguien nuevo entra en el proyecto.

Curva de aprendizaje real: explícito vs mágico

CI4 es más explícito. Cuando inyectas un servicio, lo ves. Cuando el router procesa una URL, puedes seguir el flujo. Cuando un modelo ejecuta una consulta, el query builder es transparente. No hay facades estáticas que en realidad son proxies a instancias del contenedor de servicios. No hay magia en el background que requiere conocer el framework en profundidad para depurar.

Laravel usa el principio de convención sobre configuración de forma muy agresiva. Eso acelera el desarrollo cuando conoces las convenciones, pero convierte la depuración en arqueología cuando no. Los errores de "el binding no se resolvió" o "el observer no se disparó" o "la relación Eloquent hizo N+1 sin que lo vieras" son familiares para cualquiera que haya trabajado en Laravel durante años.

En la práctica: un desarrollador PHP competente pero sin experiencia específica en Laravel necesita entre 2 y 4 semanas para ser productivo de verdad en un proyecto Laravel establecido. En CI4, ese mismo perfil suele estar contribuyendo con confianza en menos de una semana.

Para proyectos donde el cliente quizás hereda el código, donde el equipo de mantenimiento puede cambiar, o donde el presupuesto no permite onboarding largo, esa diferencia importa.

Ciclos de versión y breaking changes

Laravel tiene un ciclo de versión mayor anual. Cada versión mayor trae breaking changes. Migrar de Laravel 9 a 10, o de 10 a 11, requiere trabajo real: deprecaciones, cambios de API, paquetes de terceros que pueden no seguir el ritmo.

Para un proyecto de cliente que va a vivir 3-5 años, eso significa varias migraciones de versión mayor. Cada una cuesta tiempo, y las migraciones diferidas acumulan deuda técnica que eventualmente se paga de golpe.

CI4 tiene un ciclo más conservador. Las actualizaciones dentro de la misma versión mayor son suaves, y el equipo del framework prioriza la compatibilidad hacia atrás. Un proyecto construido en CI4 4.x hoy puede actualizarse con mucho menos fricción durante los próximos años.

Para proyectos de cliente con ciclos de vida largos y presupuestos de mantenimiento ajustados, esa diferencia es significativa.

Dependencias y superficie de ataque

Laravel instala varios cientos de paquetes Composer por defecto. Eso incluye Symfony components, Illuminate packages, y una cadena de dependencias transitivas considerable. Cada dependencia es código que tienes que auditar, actualizar, y monitorizar por vulnerabilidades.

CI4 tiene una base de código mucho más pequeña. Menos dependencias, menos superficie de ataque, menos cosas que actualizar y revisar. Para proyectos donde la seguridad es prioritaria —intranets con datos sensibles, portales de gestión de clientes, APIs que manejan información financiera— ese diferencial importa.

El trabajo de actualización de dependencias no es despreciable. composer update seguido de testing regresivo tiene un coste real que se multiplica por el número de dependencias.

Rendimiento sin configuración

En condiciones de servidor compartido o VPS pequeño (que es donde vive la mayoría de proyectos de cliente reales), CI4 es notablemente más rápido que Laravel sin configuración adicional. No porque Laravel sea lento en absoluto, sino porque el ciclo de boot de Laravel, con toda la resolución del contenedor de servicios y el registro de providers, tiene un overhead mayor.

En un servidor dedicado bien configurado con OPcache, Redis para sesiones y caché, y un stack moderno, la diferencia práctica es pequeña. Pero los proyectos de cliente rara vez viven en ese entorno ideal durante toda su vida. Muchos empiezan en hosting compartido, o en un VPS de 5€/mes, y ahí la diferencia es perceptible.

Dónde Laravel gana de verdad

Siendo honestos: hay escenarios donde elegiríamos Laravel sin dudar.

Cuando el equipo lo conoce profundamente. Si el equipo de desarrollo tiene años de experiencia real en Laravel, conoce sus patrones, sabe depurar sus peculiaridades, y tiene opiniones formadas sobre arquitectura Laravel, cambiar a CI4 sería contraproducente. El conocimiento profundo de cualquier herramienta vale más que la herramienta teóricamente superior.

Cuando el proyecto necesita paquetes específicos del ecosistema Laravel. Laravel Cashier para suscripciones con Stripe tiene una integración que no existe en CI4. Laravel Telescope para debugging en producción es genuinamente útil. Laravel Horizon para gestión de colas Redis es maduro y completo. Si el proyecto depende de esos paquetes, la elección está hecha.

Cuando el equipo supera 4-5 desarrolladores. Las convenciones de Laravel se vuelven más valiosas a medida que crece el equipo. Con muchas personas trabajando en el mismo codebase, tener convenciones fuertes y bien establecidas reduce la entropía. En equipos pequeños, esas convenciones pueden ser overhead innecesario.

Cuando el cliente necesita contratar del mercado laboral. Si la empresa cliente va a tomar el proyecto internamente y necesita contratar desarrolladores PHP, encontrar perfiles con experiencia en Laravel es mucho más fácil que encontrar perfiles con experiencia en CI4. Esa realidad del mercado tiene que pesar en la decisión.

Dónde CI4 gana con claridad

Proyectos de cliente a medida donde alguien más mantendrá el código. Este es el caso más común en nuestro trabajo. El cliente recibe el proyecto, pasa tiempo, y eventualmente otro desarrollador tiene que tocarlo. CI4 facilita esa transición.

Intranets y portales de gestión. Módulos de RRHH, portales de clientes, herramientas de backoffice, dashboards operativos. No necesitan la maquinaria completa de Laravel. CI4 cubre esos casos con menos complejidad.

Equipos pequeños con presupuestos ajustados. Menos dependencias que actualizar, menos convenciones que dominar, menos overhead de framework significa más tiempo productivo para un equipo pequeño.

APIs consumidas por apps móviles o herramientas de automatización como n8n. CI4 es particularmente limpio para construir APIs REST bien estructuradas. El router, los filtros para autenticación JWT, y el response builder son directos y fáciles de auditar.

Lo que no importa tanto como parece

El tamaño de la comunidad para desarrolladores experimentados. Cuando tienes un problema técnico real en CI4, la documentación oficial cubre el 90% de los casos. Los problemas restantes son problemas de arquitectura, no de framework, y esos se resuelven igual en cualquier framework.

El número de paquetes disponibles cuando construyes a medida. Si estás construyendo un portal a medida, no instalas 50 paquetes. Instalas 5-8 dependencias específicas. Ese ecosistema existe igualmente en CI4.

Los benchmarks de laboratorio. Las pruebas de rendimiento con hello world o queries triviales no reflejan el comportamiento real bajo carga con lógica de negocio compleja. Si el rendimiento es crítico, mide tu caso específico, no el benchmark genérico.

El criterio de decisión real

La pregunta no es "¿cuál es mejor?". La pregunta es: ¿este proyecto necesita algo que solo existe en el ecosistema de Laravel, o el equipo tiene un conocimiento profundo de Laravel que sería un desperdicio ignorar?

Si la respuesta a cualquiera de esas preguntas es sí, elige Laravel.

Si la respuesta es no, CI4 produce proyectos más fáciles de mantener, más fáciles de transferir, con menos superficie de ataque, y con menos overhead operativo a largo plazo.

Esa es la decisión que tomamos cada vez que empieza un proyecto. No es dogmática ni permanente. Es contextual. Y en la mayoría de proyectos de cliente con los que trabajamos, CI4 es la elección correcta por razones que tienen poco que ver con qué framework tiene más estrellas en GitHub.