Aplicaciones Laravel y PHP
Aplicaciones Laravel hechas para entregarse.
Portales de clientes, facturación por suscripción, herramientas internas y las APIs que las conectan con todo lo demás que usas. Tipadas, probadas donde importa y documentadas lo suficiente como para que puedas reemplazarme sin dramas, que es la única definición honesta de un proyecto terminado.
01AlcanceQué construyo
Los tipos de aplicación que esto suele significar.
Portales para clientes y socios
Un lugar donde tus clientes inician sesión para ver sus propios datos: pedidos, facturas, documentos, consumo, derechos de acceso. Lo difícil casi nunca son las pantallas. Es el modelo de permisos, el registro de auditoría y lo que pasa cuando una cuenta necesita seis usuarios con accesos distintos.
Facturación por suscripción y por factura
Planes, prorrateo, condiciones de crédito, gestión de impagos, impuestos, facturas en PDF y el informe de conciliación en el que tu equipo de finanzas realmente confía. Construyo la facturación sobre un libro de partida doble y no sobre un total acumulado, porque un total acumulado es imposible de auditar el día en que alguien disputa un cargo.
Herramientas internas que reemplazan una hoja de cálculo
El flujo de trabajo que hoy vive en una hoja de cálculo compartida, con sus conflictos de versiones y esa única persona que la entiende. Convertirlo en una aplicación suele ser el trabajo con mayor retorno que una empresa puede encargar, y normalmente el más pequeño.
APIs e integraciones
Endpoints REST o GraphQL para tu propio front end, tu app móvil o un socio. Más el trabajo de integración que conecta Laravel con todo lo demás que usas: un ERP, un CRM, un proveedor de pagos, un sistema de almacén.
Hacerme cargo del código de otra persona
Empiezo estos proyectos con una semana de solo lectura: ejecuto las pruebas si existen, mapeo los modelos del dominio y dejo por escrito lo que encuentro, incluidas las partes que me preocupan. Recibes esa evaluación continúes o no, así que nunca pagas solo para que te digan que el código está bien.
02MétodoA dónde va el dinero
En qué invierto tu presupuesto.
La mayoría de los presupuestos de aplicaciones se pierden en los mismos tres lugares, así que ahí va el cuidado, y no en las partes que lucen bien en una demo.
El modelo de datos, antes que nada
Las decisiones de esquema son las que no se pueden revertir barato. Una migración que divide una tabla en tres a los dieciocho meses, con datos reales de clientes y un conjunto de informes apuntando a ella, es el día más caro en la vida de un proyecto. Prefiero dedicar dos días extra al esquema que dos semanas extra a esa migración.
Todo lo que toca dinero o permisos
La facturación, los roles y todo lo que escribe en un libro contable llevan pruebas. No por una insignia de cobertura, sino para que la próxima persona pueda cambiar tu lógica de precios sin romper en silencio las facturas del trimestre pasado. En el resto pruebo los caminos incómodos y dejo en paz los obvios.
Qué pasa cuando otra cosa falla
Una integración no está terminada cuando funciona. Está terminada cuando se comporta con sensatez mientras el otro sistema no responde. Eso significa trabajos en cola, reintentos limitados, claves de idempotencia y un registro de fallos que una persona pueda leer, para que una mala tarde de un proveedor retrase tus datos en lugar de perderlos.
Nada de esto es exótico. Es Laravel normal, hecho con cuidado. La diferencia se nota en el segundo año, que es justo cuando la mayoría de las agencias ya se fueron y descubres qué compraste en realidad.
03EntregaLo que es tuyo al final
El entregable no es solo la aplicación funcionando.
- 01
El repositorio
- En tu organización, no en la mía, desde el primer commit. Con el historial intacto y mensajes de commit que explican el porqué, no solo el qué.
- 02
Un documento de arquitectura
- Unas pocas páginas sobre los modelos del dominio, las decisiones que tomé y las alternativas que descarté y por qué. Es el documento que le ahorra quince días a tu próximo desarrollador.
- 03
Un entorno local que funciona
- Un desarrollador nuevo debería pasar de clonar el repositorio a tener la aplicación funcionando en menos de una hora, con seeders que generan datos realistas. Si eso toma un día, el proyecto no está terminado.
- 04
Notas de despliegue y reversión
- Cómo se despliega, cuáles son las variables de entorno, a dónde van los respaldos y cómo revertir a las dos de la mañana sin llamarme.
04PreguntasFrecuentes, respondidas sin rodeos
Lo que la gente pregunta antes de contratarme.
¿Esto debería ser una aplicación Laravel o un sitio WordPress?
Si el trabajo principal es publicar páginas que editan personas no técnicas, WordPress suele ser más barato y rápido. Si el trabajo principal es que los usuarios inicien sesión y hagan algo (pedir, reservar, aprobar, generar informes), eso es una aplicación. Forzar una aplicación dentro de WordPress generalmente cuesta más a lo largo de dos años que construirla bien una sola vez.
¿Puedes hacerte cargo de un código existente?
Sí, y es una buena parte de mi trabajo. Empieza con una semana de solo lectura que produce una evaluación por escrito: qué hay, qué es riesgoso y qué haría primero. Ese documento es tuyo decidas lo que decidas después.
¿Escribes pruebas?
En todo lo que involucra dinero, permisos o integridad de datos, sí. No persigo un porcentaje de cobertura: una suite llena de pruebas que verifican que los getters devuelven valores es un costo de mantenimiento disfrazado de calidad. La suite existe para que alguien pueda cambiar tu facturación sin romperla.
¿Cómo manejas el despliegue y el hosting?
Con lo que ya tengas: un VPS, Forge, Ploi, Vapor, contenedores. Si todavía no tienes nada, te recomendaré lo más simple que se ajuste a tu tráfico. Para la mayoría de las aplicaciones de negocio, eso es un servidor bien configurado con respaldos gestionados de la base de datos, no un clúster.
¿Puedes integrarte con nuestro ERP o CRM?
Normalmente sí. La verdadera pregunta nunca es si se puede, sino cómo se comporta cuando el otro sistema está lento o caído. Trabajos en cola con reintentos limitados y un registro de fallos legible, para que su caída retrase tus datos en lugar de perderlos.
¿Y si necesito cambios después del lanzamiento?
El repositorio y la documentación son tuyos, así que puedes contratar a quien quieras. Si prefieres seguir conmigo, ofrezco un bloque mensual de horas. Lo que intento evitar es volverme estructuralmente imprescindible: una aplicación que solo yo puedo mantener es un riesgo para ti, no una ventaja para mí.
Siguiente paso
Describe el flujo de trabajo que quieres reemplazar.
Incluso una descripción aproximada me basta para decirte si es un trabajo de dos semanas o de dos trimestres, y qué partes podrías dejar fuera de la primera versión.