- Crónica práctica de un desarrollador en solitario que desarrolló y mantuvo todo el servicio con Rails y alcanzó 1 millón de euros de ARR (ingresos recurrentes) al año
- Al principio comenzó solo con un MVP básico, pero lo hizo crecer hasta una estructura mantenible mediante una reescritura completa y mejoras de arquitectura
- La clave fue la filosofía coherente de Rails, sus componentes y la capacidad de responder a móviles mediante Turbo Native
- Una arquitectura eficiente que permitió operar con menos de 1.500 euros mensuales en costos de servidores mientras soportaba todo el tráfico y uso
- Al final, vendió una parte de su participación a un inversionista orientado al largo plazo y, 14 años después, contrató a su segundo desarrollador, entrando en una nueva etapa
Aplicación práctica de The One-Person Framework
Alcanzar 1 millón de euros de ARR solo con Rails
- A inicios de 2022, PlanGo superó 1 millón de euros en ingresos recurrentes anuales (ARR), un logro que parecía un sueño para un servicio construido con una sola base de código en Rails y un solo desarrollador
- Todas las áreas no técnicas —definición de visión, captación de clientes y estrategia de crecimiento— quedaron a cargo del cofundador y el equipo de soporte al cliente, pero desde el diseño de arquitectura hasta el despliegue, la operación y la implementación de frontend y backend, todo lo hizo una sola persona
- Lo que DHH planteó como “One Person Framework”, es decir, una estructura en la que un solo desarrollador puede administrar toda la aplicación, quedó demostrado en la práctica, no solo en teoría
- La filosofía estructural de Rails —que permite trabajar el diseño de base de datos, la lógica de negocio y la UI del frontend dentro de un conjunto coherente de herramientas— favorece especialmente a equipos pequeños o fundadores en solitario
- Este texto está escrito para personas como las siguientes:
- Desarrolladores Rails: quienes se preguntan si hoy todavía es posible construir un gran producto por cuenta propia
- Fundadores técnicos: quienes cargan con muchos roles y sienten el peso de esa responsabilidad
- Personas que valoran el oficio y la elección tecnológica
La situación al comenzar
- En 2011, el autor, con 21 años y trabajando antes en proyectos de PHP(CodeIgniter), empezó a usar Rails
- No había una gran estrategia; todo comenzó por una motivación simple de probar Rails siguiendo la tendencia
- A partir de una idea de marketing del cofundador, lanzaron una oferta: quienes se registraran durante la semana de lanzamiento tendrían un año gratis
- Esperaban apenas unas decenas de personas, pero en realidad se registraron más de 500 en la primera semana
- Como el producto estaba al nivel de un MVP, enseguida llegaron cientos de solicitudes de funciones, preguntas y pedidos de soporte
- El servidor aguantó bien, pero la demanda del cliente explotó cuando el producto todavía no estaba listo
- Ninguno de los dos cofundadores podía responder de tiempo completo porque ambos tenían otros trabajos
- Como resultado, no quedó más remedio que decepcionar a muchos de los primeros usuarios
- Esa experiencia dejó claro que “desarrollar software” y “operar un negocio de software” son problemas completamente distintos
- La lección fue que no basta con implementar funciones; también hace falta atención al cliente sostenible, gestión de expectativas y un sistema operativo del servicio
Aprender mientras se construye
- Empezó a desarrollar apoyándose en tutoriales de Rails y Stack Overflow, pero construir una aplicación de producción responsable de un negocio real de clientes era algo de otra dimensión
- El código inicial en Rails incluía errores típicos de principiante como estos:
- Métodos de controlador de más de 200 líneas
- Modelos gigantes con responsabilidades mezcladas
- Consultas SQL ineficientes
- Ausencia de pruebas
- Valores de configuración y claves secretas commiteadas en Git
- Era posible implementar funciones, pero toda la aplicación dependía de código improvisado y una estructura inestable
- Funciones como autenticación de usuarios, carga de archivos, generación de PDF, UI de administración y manejo de correo se implementaron rápido apoyándose en Gems, pero con el tiempo cada Gem introdujo nueva complejidad y nuevos problemas
- Al usar
.round(2), se aplicó "banker's rounding" de una manera distinta a la esperada y eso provocó errores en el cálculo de montos
- Incluso en cálculos simples, delegar demasiado a Gems externas terminó revelando una falta de comprensión de fondo sobre el manejo numérico
- Hacia 2013, a medida que se acumulaba experiencia operando el producto, la deuda técnica también crecía rápidamente y cada vez era más difícil desarrollar nuevas funciones
Reescritura total
- Aunque una reescritura completa suele considerarse una decisión riesgosa e ineficiente, en 2014 se tomó la decisión de reconstruir todo desde cero sobre Rails 4
- Durante meses se mantuvo la aplicación existente mientras, al mismo tiempo, se desarrollaba la nueva base de código con trabajo intensivo en paralelo
- Se simplificó la arquitectura, se redujo a menos de la mitad la dependencia de Gems y se introdujeron pruebas en las funciones clave
- La nueva estructura resultó más simple y rápida que la anterior, y sobre todo fue diseñada para poder ser mantenida por un único desarrollador de tiempo parcial
- Esa reescritura se convirtió en la base técnica que después permitiría más de 10 años de operación por un desarrollador en solitario
Rails es un superpoder
- Hasta 2025, PlanGo fue operado por una sola persona, y la razón principal que hizo eso posible fue Rails
- Gracias a características estructurales de Rails como Convention over Configuration, pruebas integradas, ActiveRecord, ActiveStorage y ActiveJob, fue posible minimizar decisiones no esenciales y concentrarse en crear valor real
- Tras adoptar Turbolinks y Hotwire, también fue posible construir una UI moderna sin recurrir a frameworks JS complejos
- En los primeros años de desarrollo, en 2011, casi no había demanda de apps móviles, pero después las apps de iOS/Android se convirtieron en la interfaz principal de PlanGo
- Se probaron varios frameworks como Titanium, RubyMotion y Objective-C, enfrentando el problema de equilibrar calidad y velocidad
- Después de adoptar Turbo Native, la productividad mejoró drásticamente y con conocimientos básicos de desarrollo nativo ya era posible construir apps de alta calidad aprovechando la base de código en Rails
- Este enfoque es especialmente ideal para apps B2B o SaaS, ya que permite lograr rendimiento y experiencia nativos con un costo de desarrollo reducido
- Como resultado, logró más de 100.000 descargas de la app al año e incluso superó temporalmente a Duolingo en la App Store de los Países Bajos
- Todas las apps fueron desarrolladas y mantenidas por un solo desarrollador de Rails
- Métricas principales:
- Código Ruby: 36,170 líneas
- Código JavaScript: 13,495 líneas
- Cobertura de pruebas: 40%
- Usuarios activos diarios: 6,332
- Solicitudes por minuto en hora pico: 7,000
- Costo mensual de servidores: menos de €1,500
- Mantener una arquitectura monolítica estructurada fue una de las mejores decisiones, y permitió desplegar fácilmente con Capistrano y depurar sin la complejidad de los microservicios
- Para un fundador técnico, Rails no es solo un framework, sino un superpoder que permite que una sola persona haga el trabajo de un equipo completo
Más allá del millón de euros
- A finales de 2022 llegó un punto de inflexión inesperado: un inversionista extranjero mostró interés en PlanGo y presentó una oferta de adquisición
- En ese momento, PlanGo ya había superado €1M de ARR de forma bootstrapped, y aun sin financiamiento externo mantenía una estructura de ingresos sostenible y una operación eficiente
- Esa propuesta llevó al equipo a plantearse la pregunta: "¿Qué queremos de aquí en adelante?"
- Se exploraron varias posibilidades: mantener el modelo actual, escalar con capital externo o vender por completo
- Aunque el cariño por el negocio seguía siendo profundo, también surgió la idea de que con más recursos y especialización sería más fácil ejecutar nuevas oportunidades
- Desde el punto de vista de materializar valor, recuperar parte del valor construido durante más de 10 años mientras el negocio seguía creciendo era una opción razonable
- La decisión final fue asociarse con un fondo evergreen de los Países Bajos cuyos valores y visión de largo plazo encajaban bien
- Se vendió una parte de la participación, pero se mantuvo el control y la mayoría accionaria
- Se obtuvieron recursos adicionales sin dañar la estructura ni la cultura existentes
- Esta decisión no fue un exit de corto plazo ni una expansión agresiva, sino parte de una estrategia de crecimiento estable basada en un negocio sostenible y centrado en el cliente
- Después de eso, el enfoque basado en Rails se mantuvo intacto, pero se abrió una nueva etapa en la que fue posible perseguir con más decisión oportunidades que antes eran difíciles de intentar
Lo aprendido
- Estas son algunas lecciones obtenidas tras operar PlanGo durante 14 años como fundador técnico en solitario
- Embrace Rails conventions
- Es importante no ir en contra de la filosofía y las convenciones de Rails
- El “Rails Way” es una forma de resolver problemas ya probada, y cuanto más se sigue, más fácil es concentrarse en el valor propio del producto
- Less is more
- Las Gems o librerías JS permiten implementar funciones rápidamente, pero al mismo tiempo aumentan la complejidad y la posibilidad de fallas
- Antes de agregar una nueva dependencia, siempre hay que preguntarse: "¿De verdad hace falta esto?"
- Find a community
- Para un desarrollador en solitario, la conexión con otros desarrolladores Rails es muy importante
- Por ejemplo, la comunidad que surgió al crear Spina CMS se convirtió en un vínculo valioso para compartir conocimiento y recibir feedback, aunque no fueran compañeros de trabajo
- Technical debt isn't always bad
- A veces, una decisión práctica para llegar rápido al mercado puede ser mejor que la perfección técnica
- La clave con la deuda técnica está en distinguir conscientemente cuándo asumirla y cuándo pagarla
- You can go far alone
- Con Rails, un solo desarrollador puede diseñar, escalar y desplegar un producto del tamaño de un equipo completo
- No hace falta quedar atrapado en la idea común de que “siempre se necesita un equipo”
Lo que viene
- El nuevo socio inversionista estuvo de acuerdo con la forma de operación ligera de PlanGo, pero puso una única condición: sumar un desarrollador Rails más
- El problema no era aferrarse al desarrollo en solitario, sino la dificultad misma de incorporar a una nueva persona a una base de código que había evolucionado durante 14 años
- La base de código no solo reflejaba la evolución de PlanGo, sino también toda la historia personal de crecimiento del autor, de principiante a desarrollador experimentado, y
mezclaba decisiones y estilos de código producidos por distintas versiones de sí mismo a lo largo del tiempo
- Al contratar al segundo desarrollador Rails que conoció en Rails World (Canadá), surgieron cambios estructurales e impactos positivos
- Se eliminó el riesgo técnico de un único punto de falla
- Entraron nuevas perspectivas e ideas
- Mejoró la calidad del código mediante pair programming
- Apareció el estímulo intelectual de colaborar con otro desarrollador que comparte el mismo lenguaje
- No hay planes de formar un gran equipo de desarrollo en el futuro
- Como ya se ha demostrado hasta ahora, con un enfoque basado en Rails también es posible que un equipo pequeño pero fuerte construya software significativo
- Aun así, también quedó claro que incluso el desarrollador en solitario más eficiente puede crecer más con buenos compañeros de equipo
- El recorrido de PlanGo muestra que el One-Person Framework de Rails realmente funciona, y
demuestra que un equipo pequeño con las herramientas adecuadas puede construir un negocio serio según sus propios criterios
- Ya sea para un desarrollador en solitario creando su primer producto o para un equipo pequeño que evalúa su stack tecnológico, ojalá esta historia muestre lo que puede lograrse cuando se aprovecha Rails al máximo
4 comentarios
Probé hacer un pódcast de este contenido con el resumen de audio de NotebookLM.
https://notebooklm.google.com/notebook/…
A este nivel está excelente. Todavía tengo que pulirlo más.
Guau... es impresionante... de verdad. Qué natural se siente.
Y la información se entiende clarísimo...
Opiniones en Hacker News
Hay un usuario con experiencia similar a Django que opera su propia app
Hay un usuario que sostiene que la persona es más importante que el framework
Hay un usuario que comparte su experiencia usando Rails y Phoenix
Hay un usuario que comentó que dio una charla sobre cómo Rails 7+ ayuda incluso a desarrolladores solistas a construir apps ambiciosas
Hay un usuario que compartió una experiencia en la que un nuevo socio quería sumar desarrolladores de Rails
Hay un usuario que está construyendo una app con AdonisJS
Hay un usuario que piensa que Rails supera a Django en varios aspectos
Hay un desarrollador solista que está construyendo una app con Rails
Hay un usuario que sostiene que se deben evitar las reescrituras completas
Hay un usuario que cree que el framework no es tan importante