De 10 Ideas a Una Sola: Cómo Elegimos Qué Construir para Ship-a-ton 2026

En BerylCode queríamos que Ship-a-ton fuera algo más que un proyecto de hackathon. Queríamos usarlo como un caso público de cómo trabajamos: entender un problema, crear hipótesis, investigar, diseñar, construir, monetizar, lanzar, medir y mejorar.

La parte difícil no fue generar ideas (ya que entre lo que investigamos, teniamos previstos 10 temas de distinta indole para elegir), sino decidir qué problema valía la pena investigar, diseñar, construir, monetizar, probar y publicar en las siguientes semanas.

Lo que pensábamos

Algunas de esas ideas generadas eran más divertidas y nos daban más emoción. Otras tenían más potencial visual. Algunas parecían más fáciles de monetizar... Pero sabiamos que una apreciación como: “nos gusta esta idea” no era suficiente, y empezamos a hacernos preguntas más prácticas:

• ¿Con qué frecuencia ocurre este problema?
• ¿Podemos construir un MVP útil en el tiempo disponible?
• ¿Se puede entender el producto en 30–60 segundos?
• ¿Existe una razón natural para volver?
• ¿Podemos monetizarlo sin dañar la experiencia?
• ¿Hay espacio para hacer algo diferente?
• ¿Este proyecto nos permite mostrar lo que BerylCode puede hacer en research, UX, diseño visual y desarrollo?

De ahí salió nuestro primer framework de evaluación, ordenando las ideas según criterios como potencial frecuencia de uso, facilidad de MVP, potencial de crecimiento o compartibilidad, potencial visual, monetización, diferenciación y encaje con Ship-a-ton. El objetivo no era crear un ranking matemático perfecto, sino hacer visibles nuestras suposiciones.

Lo que encontramos

La competencia no significa automáticamente que una idea esté descartada.

Durante las investigaciones de escritorio y benchmarking realizadas, vimos que nueve de nuestras diez ideas tenían competidores directos o indirectos... En vez de descartar automáticamente esos espacios, empezamos a preguntarnos:

¿Qué es lo que estos servicios están resolviendo bien y qué están dejando sin resolver?

Por ejemplo, cuando exploramos las ideas relacionadas con el "espacio de pausas y bienestar", encontramos productos con enfoques muy diferentes. Ver esas diferencias fue más útil que simplemente contar cuántos competidores existían, ya que nos mostró que un mercado, aun con competencia "directa" puede seguir teniendo filosofías de producto muy distintas.

Al principio pensábamos que crear una solución alrededor de problemas frecuentes, podría ser más seguro que apuntar a problemas ocasionales, o que una idea con un buen gancho visual o muy gamificada, podría tener ventaja en una competencia donde el producto necesita entenderse rápido.

Pensamos incluso que la competencia directa e indirecta podría ser casi como una señal de alerta: "Si ya había muchas apps alrededor de una idea, quizás no habría forma de crear algo distinto en ese nicho. "Sin embargo, esa idea cambió bastante rápido. Cambiamos la pregunta de: “¿Ya existe esto?” a:

• “¿Qué está resolviendo bien este mercado y qué sigue quedando incómodo, mal resuelto o demasiado genérico?”
• "¿Qué tipo de riesgo / oportunidad podríamos probar en pocas semanas?

Lo que cambiamos

Dejamos de comparar ideas solo porque sonaban atractivas y empezamos a compararlas por el tipo de producto que podria resultar o llegar a construir. La idea propuesta sobre personas que pasan largos periodos concentradas, sentadas o frente a una pantalla y llegan al final de un bloque — o incluso al final del día — sintiendo que casi no cambiaron de postura, no descansaron la vista o no se alejaron de la actividad empezó a hacerse más visible.

En ese momento creabamos hipotesis alrededor de pausas muy cortas, una criatura o compañero que reaccionara positiva o negativamente a la realización / ausencia de las pausas, y una experiencia centrada especialmente en personas con jornadas sedentarias.

Todavía no sabíamos si esa era la solución correcta, pero ya teníamos un problema suficientemente concreto para investigar y poder avanzar.

Por qué esta idea sobrevivió

Esa no era necesariamente la idea más viral, ni tampoco la más fácil de todas, sin embargo, tenía una combinación que nos interesaba:

• Un problema cotidiano y reconocible;
• Un funcionamiento básico sencillo y fácil de entender;
• Utilidad incluso para una sola persona;
• Oportunidad de trabajar interacción y diseño visual;
• Un reto real alrededor de notificaciones y retención;
• Espacio para monetización;
• Suficiente incertidumbre como para que la investigación realmente aportara valor.

Además, nos permitía poder mostrar varias capacidades de BerylCode dentro de un mismo proyecto:

research → product framing → UX → visual design → engineering → monetization → analytics → iteration.

Lo que todavía no sabemos

Elegir el problema no significa haber elegido ya el producto. Siguen algunos inciertos como:

• ¿Cuánto debía durar una pausa?;
• ¿Si debía haber distintos tipos?;
• ¿Cuánto protagonismo debía tener el compañero virtual?;
• ¿Si la app debía ser casi invisible o más expresiva?;
• ¿Cuánto debía decidir el sistema?;
• ¿Cuánto debía configurar el usuario?;
• ¿Qué hacía realmente molesto o útil a un recordatorio?.

E incluso, algo más importante, y es el comprobar si nuestra interpretación del problema coincidía con la experiencia real de las personas.

Qué probamos después

El siguiente paso fue salir de nuestras propias suposiciones, y diseñamos nuestra investigación alrededor de preguntas como:

• ¿Cuánto tiempo pasan las personas en bloques de baja movilidad?
• ¿Qué les impide pausar?
• ¿Qué hacen naturalmente cuando sí se levantan?
• ¿Qué vuelve molesto un recordatorio?
• ¿Cuánto control quieren?
• ¿Qué tipos de pausa tienen sentido en un día normal de trabajo?

En el siguiente Blog, compartiremos qué ocurrió cuando empezamos a probar con las personas y qué partes de nuestra idea original realmente sobrevivio al contacto con la realidad. ¡No se lo pierdan!