Por qué y cómo decidimos usar Ruby on Rails 8

Por qué Mi Carrito App migró su backend a Rails 8, los trade-offs detrás de la decisión y cómo pensamos la tecnología desde el punto de vista del producto.

Por qué Mi Carrito App está migrando a Rails 8 en el backend

Mi Carrito App nació como nacen muchos productos:
con una idea clara, poco tiempo y la urgencia de salir rápido al mercado.

En ese momento, la pregunta no era “¿cuál es la mejor arquitectura?”, sino algo mucho más simple:

"

¿cómo validamos esta idea lo antes posible?

Hoy el proyecto está en una etapa distinta. Ya no se trata solo de probar, sino de construir algo sostenible, fácil de mantener y que nos permita avanzar sin que la complejidad se vuelva un freno.
Por eso tomamos una decisión importante: migrar el backend a Rails 8.

Este post está pensado tanto para personas que construyen productos como para quienes también están del lado técnico: lenguaje claro, contexto real y sin tecnicismos innecesarios.

Cuando el MVP empieza a crecer

El stack original cumplió su función.
Nos permitió lanzar, aprender rápido y confirmar que el producto tenía sentido.

Pero con el tiempo empezaron a aparecer algunas señales claras:

• Cada nueva funcionalidad tomaba más tiempo del esperado
• Mantener el código requería más esfuerzo
• Cambios pequeños implicaban tocar varias partes del sistema
• La velocidad de iteración empezó a bajar

Nada estaba “roto”, pero el costo mental y técnico empezó a subir.

Y cuando eso pasa, normalmente no es un problema de personas, sino de decisiones técnicas que funcionaron para el MVP, pero no para la siguiente etapa.

La decisión: priorizar velocidad y claridad

Migrar un backend no es una decisión ligera.
Toma tiempo, energía y no genera mejoras visibles de inmediato para el usuario.

Entonces, ¿por qué hacerlo?

Porque hoy Mi Carrito App necesita:

• Iterar rápido
• Reducir complejidad
• Tener una base clara y mantenible
• Poner el foco en el producto, no en la infraestructura

Con esos objetivos en mente, Rails 8 encajó de forma natural.

¿Por qué Rails 8?

Rails no es el framework más “de moda”, pero sigue siendo uno de los más efectivos para construir productos reales.

Estas son algunas de las razones principales.

Convención sobre configuración

Rails reduce la cantidad de decisiones innecesarias.
Eso significa menos fricción y más foco en resolver problemas reales del negocio.

En la práctica, esto se traduce en:

• Menos errores
• Menos código repetido
• Un onboarding más rápido

Velocidad de desarrollo

Rails está pensado para construir funcionalidades, no para pelear con la infraestructura.

Para un producto en crecimiento, eso implica:

• Menos tiempo escribiendo código repetitivo
• Más tiempo mejorando la experiencia del usuario

Un ecosistema integrado y maduro

Rails no es solo un framework, es un ecosistema completo:

• Backend
• ORM
• Jobs en segundo plano
• Testing
• Hotwire para interactividad sin depender de grandes capas de JavaScript

Todo está diseñado para trabajar en conjunto, no como piezas pegadas a la fuerza.

Ideal para equipos pequeños

Mi Carrito App no es una empresa con decenas de ingenieros backend.

Rails funciona especialmente bien cuando:

• El equipo es pequeño
• El producto cambia con frecuencia
• Se necesita claridad y orden para avanzar

Lo que Rails no es (y por qué está bien)

Para ser justos, Rails no es la solución perfecta para todos los casos.

Algunas realidades:

• No es el stack más trendy
• La migración tiene un costo inicial
• No está pensado para sistemas ultra distribuidos desde el día uno

Pero hoy Mi Carrito App no necesita eso.

Necesita algo mucho más simple:

"

claridad, velocidad y foco en el producto.

¿Para quién tiene sentido esta decisión?

Rails 8 es una muy buena opción si:

• Estás construyendo un SaaS o producto digital
• Necesitas iterar rápido
• Tu equipo es pequeño
• Prefieres estabilidad y madurez antes que hype

Probablemente no sea la mejor opción si:

• Tu principal reto es solo infraestructura
• Necesitas escalar masivamente desde el inicio
• Quieres experimentar con stacks complejos por sí mismos

Más allá del framework

Esta migración no se trata de Ruby ni de Rails.

Se trata de tomar decisiones técnicas alineadas con el momento real del producto.

Las herramientas no son una identidad.
Son medios para construir algo que funcione hoy y pueda crecer mañana.

Rails 8 nos permite hacer exactamente eso.

Lo que sigue

Durante la migración iremos compartiendo:

• Aprendizajes
• Retos reales
• Decisiones técnicas
• Qué funcionó y qué no

Porque construir productos no es solo escribir código.
Es aprender constantemente y ajustar el rumbo cuando hace falta.