Producto

Cómo hicimos Ranquea, un SaaS para ligas fotográficas, con un equipo de dos

Ranquea empezó como una petición concreta: Miradas Ceuta, una asociación fotográfica local, quería organizar una liga con retos temáticos, jornadas y ranking, y no encontraba una herramienta que hiciera eso sin retorcerla. La opción fácil habría sido montarles un WordPress con dos plugins y facturar. La opción interesante era distinta: construir un producto de verdad, uno que después pudiera usar cualquier colectivo del mundo. Álvaro y yo elegimos la segunda. Esto es cómo lo hicimos siendo dos personas, sin financiación externa y sin dejar de atender proyectos de clientes.

Escribo esto porque la mayoría de guías "cómo construir un SaaS" están firmadas por equipos con diez desarrolladores y un año de runway. La nuestra sirve más para quien va a empezar sabiendo que el equipo cabe en un coche y el tiempo se roba entre proyectos que sí pagan.

Primera decisión: no construir un producto, construir un motor

Lo que nos habrían pagado por hacer era una web de Miradas Ceuta con votación de fotos. Lo que nos costaba parecido en tiempo era construir el motor que hay detrás. La regla que nos dimos fue clara: cada línea de código tiene que servir a más de un caso. Si algo era específico de Miradas iba a la capa de configuración, no al núcleo. Fue lo que después nos permitió acoger a otro colectivo sin tocar el sistema.

El coste de esa decisión: seis semanas de más al principio para separar producto de proyecto. La recompensa: cada colectivo nuevo entra en horas, no en semanas.

Lo que decidimos NO construir

Con dos personas no puedes con todo. Estas fueron las cosas grandes que se quedaron fuera del alcance, y algunas siguen fuera hoy:

• Chat en vivo entre participantes. Un colectivo fotográfico ya se comunica por su Telegram o su WhatsApp; duplicar ese canal era ruido.
• Editor de imágenes dentro de la plataforma. Cada fotógrafo tiene su Lightroom, su móvil o su método. La plataforma recibe la foto ya editada.
• Panel de analítica avanzada para el organizador. Empezamos con una exportación a CSV y funcionó. Los gráficos bonitos habrían costado semanas para una decisión que se toma con la misma información en una hoja de cálculo.
• App nativa. Web responsive primero; el 90 % de los usos son "subo foto y voto" y no piden notificaciones push.

Cada "no" fue incómodo cuando alguien lo pidió. Cada uno nos ahorró meses. La disciplina para decir que no es probablemente la habilidad más rentable de un equipo pequeño.

Lo que sí decidimos hacer a medida

El motor: retos, jornadas, votación de jurado, ranking en directo, galerías públicas. Ahí vive el producto. Y una pieza que no habíamos previsto pero se volvió crítica: el sistema de puntuación configurable. Cada colectivo puntúa distinto —tres jueces, cinco jueces, con peso o sin peso, votación abierta o privada— y hacerlo genérico era el 20 % del trabajo que resolvía el 80 % de los casos. Sin esa capa, cada nuevo cliente habría requerido tocar código.

Lo que compramos hecho

Aquí es donde muchos equipos pequeños se hunden: reconstruyendo cosas que ya existen bien resueltas. Nosotros pagamos por:

• Autenticación con un proveedor externo. Nunca vamos a hacer contraseñas mejor que quien se dedica solo a eso.
• Almacenamiento de imágenes con transformaciones (redimensiones, thumbnails, entrega optimizada). Reimplementarlo era mes y medio de trabajo; contratarlo, unos euros al mes por colectivo activo.
• Correo transaccional. Mismo argumento.
• Pasarela de pago para futuros planes de suscripción. Aún no la usamos, pero está integrada porque venía casi gratis con el proveedor de autenticación.

Regla nuestra: si tu diferencial no está en construirlo, no lo construyas. La escribimos en la pizarra el primer día y todavía sirve para cortar en seco cualquier tentación de "y si nos hacemos nuestro sistema de X…".

Una arquitectura que un equipo de dos puede mantener

Cuando sois dos, cada tecnología nueva es una que alguien tiene que despertarse a las tres de la mañana a arreglar. Nos autoimpusimos una base de datos, un lenguaje en backend, un framework en frontend. Nada de microservicios; un monolito bien organizado, desplegado en un solo sitio. Poco glamouroso. Muy sostenible. Cuando la temporada 2025-26 de Miradas terminó sin una sola caída relevante, quedó claro que había sido la decisión correcta.

El equipo pequeño no pierde por elegir tecnologías aburridas. Pierde por elegir demasiadas.

Tres cosas que nos habrían ahorrado meses

1. El usuario que participa no es el que decide. El fotógrafo sube fotos; el organizador es quien adopta la plataforma. Diseñar la experiencia del organizador —crear liga, configurar puntuación, publicar resultados— nos costó al principio menos cariño del que merecía. Cuando cambiamos el foco, la adopción cambió también.
2. La cola larga de configuración vale más que muchas funcionalidades. Un colectivo con un método propio no quiere una plataforma con 50 funciones que no usa; quiere una con 10 que se doblan a su forma de trabajar. Cada opción configurable evita una funcionalidad específica del cliente en el core.
3. Ser dos obliga a decidir bien. Suena a excusa, pero es literal: no hay capacidad para ir por dos caminos a la vez, así que cada decisión importante se debate en serio. No es cómodo. Produce mejor producto que un equipo grande donde cada rama coge un camino y luego no las junta nadie.

---

¿Hablamos? Si te estás planteando construir algo parecido —un producto propio, tuyo, dentro de tu negocio— y no sabes si el equipo llega, cuéntanos tu caso. Te decimos lo que pensamos, aunque la respuesta sea "esto no es a medida, es un SaaS que ya existe".