Durante más de un año fui el único desarrollador de una plataforma SaaS para empresas de ingeniería y arquitectura. Sin equipo de backend ni de frontend. Sin reuniones de arquitectura con cinco seniors debatiendo trade-offs. Solo yo, un editor, y una lista interminable de cosas que construir.
Esto es lo que aprendí — y lo que haría diferente.
El punto de partida
Llegué cuando la empresa tenía un MVP básico. Mi misión: convertirlo en una plataforma modular que usarían equipos reales en su día a día. Presupuestos, facturas, gestión de proyectos, control de asistencias, notificaciones, calculadora de precios, sistema de matching por geolocalización...
Todo sobre Laravel + React, desplegado en DigitalOcean con GitHub Actions para CI/CD.
Lo que nadie te cuenta de ser el único dev
Tomas todas las decisiones arquitectónicas. Y eso tiene un precio.
Cada decisión tiene consecuencias reales que pagas semanas o meses después. Elegí mal el modelo de datos en un módulo y pasé semanas refactorizando. Elegí bien en otro y escalar fue trivial.
Pero el aprendizaje más importante no fue sobre sintaxis ni frameworks: fue entender que la arquitectura correcta no es la más elegante, es la que te deja iterar rápido sin que todo explote.
Y hay un aspecto que suele ignorarse hasta que duele: la capacidad del servidor desde el diseño. Es fácil construir algo que funciona perfecto con 50 registros y se cae de rodillas con 50.000. Si no piensas en los límites de memoria, en cuántas queries se disparan por request, en cómo crece el dataset con el tiempo, tarde o temprano producción te va a dar esa lección gratis.
La performance no es un problema de futuro. Es una decisión de hoy.
El sistema de matching por geolocalización era aparentemente simple: conectar profesionales disponibles con proyectos cercanos filtrando por especialidad y distancia. Funciona bien al principio. Pero cuando el dataset crece, una query que tardaba 80ms pasa a tardar 2 segundos. Y cuando hay varios usuarios consultando a la vez, el servidor empieza a sudar.
La solución pasa por pensar en capas: índices bien diseñados, consultas paginadas desde el principio, y caching estratégico. Integré Redis para cachear resultados de búsquedas frecuentes y para gestionar colas de tareas pesadas — generación de PDFs, envío de notificaciones — fuera del ciclo de request/response. El impacto fue inmediato: menos carga en el servidor, respuestas más rápidas, y usuarios que no saben que existe pero lo agradecen.
La lección: Redis no es una optimización que añades cuando ya hay problemas. Es parte del diseño desde el principio si sabes que vas a tener carga real.
Eres el que hace el deploy a las 2am
Porque hay un bug crítico en producción y los usuarios no pueden facturar. Implementé CI/CD con GitHub Actions desde el principio para reducir estos momentos, pero inevitablemente ocurren.
La diferencia entre sobrevivir a esas noches y hundirte en ellas está en cuánto puedes revertir en 5 minutos. Rollbacks rápidos no son un lujo — son infraestructura básica.
La deuda técnica no espera
Cuando tienes prisa por entregar features, atajas. Y esos atajos se convierten en el código que tienes que mantener seis meses después sin recordar por qué lo hiciste así.
El antídoto no es escribir código perfecto — es documentar las decisiones, no solo la implementación. Un comentario explicando el por qué vale diez veces más que uno explicando el qué. Especialmente cuando el único que puede leerlo eres tú mismo a las 11pm con sueño.
Los módulos que más me enseñaron
Presupuestos y facturas — No es un CRUD. Estados, transiciones, lógica de aprobación, generación de PDFs y cálculos con impuestos. En empresas grandes esto lo gestiona un equipo entero.
Gantt con carga de trabajo — Mostraba qué miembros estaban asignados a cada proyecto y su carga total acumulada. De un vistazo veías quién estaba al límite y quién tenía margen. Útil de verdad solo si el modelo de datos está bien pensado desde el principio.
Sistema de asistencias — Fichaje de entrada y salida más registro de qué se hizo en cada proyecto activo ese día. Un ciclo cerrado y estricto que daba visibilidad real sobre dónde iba el tiempo del equipo.
Integración con Google Calendar — Módulo independiente vía OAuth2. Los usuarios gestionaban su agenda y creaban reuniones vinculadas a proyectos sin salir de la plataforma.
Por qué lo volvería a hacer
Porque aprendes más en ese tiempo como único responsable que en cinco años en un equipo grande donde cada persona vive en su silo. Cuando algo falla, no puedes señalar a otro departamento. Te obliga a entender el sistema completo, de la base de datos al botón de la interfaz.
Y cuando ves a un usuario real usando algo que construiste desde cero, esa satisfacción no tiene precio.
Si estás en la misma situación
Automatiza el deploy desde el día uno. No cuando ya estés harto de hacerlo manual.
Piensa en la capacidad del servidor antes de escribir la primera línea de un módulo crítico. Lo que funciona en local con datos de prueba no siempre sobrevive a producción real.
Añade una capa de caching desde el principio en los endpoints que sabes que van a recibir carga. Redis es tu aliado, no una optimización para después.
Escribe tests para los módulos críticos, no para todo. Pero lo que no puede fallar tiene que estar cubierto.
Comunica con el negocio constantemente. Un dev solo puede construir cualquier cosa, pero construir lo incorrecto es peor que no construir nada.
Prioriza despiadadamente. No todo lo que piden tiene el mismo impacto real. Aprende a distinguirlo.
Más de un año. Una plataforma. Cero excusas para no entender cómo funciona cada pieza. Duro, pero de lo mejor que me ha pasado como ingeniero.