El estudio por dentro: cómo trabajamos de un vistazo

Hay dos formas de conocer un estudio independiente. Una es mirar lo que se ve: las apps, los juegos y las webs que desarrolla. La otra es entender todo lo que hay detrás: cómo surgen las ideas, qué decisiones se toman y qué trabajo hace posible que todo funcione.

Esta serie va de lo segundo. De cómo trabajamos por dentro, de las decisiones que tomamos antes de empezar a desarrollar y de todo lo que sucede entre una idea y un producto terminado.

Qué es CraftingBits (y qué no)

CraftingBits es un estudio independiente de apps y juegos. No somos una agencia web ni una agencia de marketing: nuestro objetivo principal es crear nuestros propios productos y construir un negocio sostenible a partir de ellos.

Eso no significa que no trabajemos para clientes. También desarrollamos proyectos externos, pero seleccionamos aquellos que nos interesan y en los que creemos que podemos aportar algo. Si un proyecto no encaja con nuestra forma de trabajar o con lo que queremos construir, preferimos no aceptarlo.

La idea original era sencilla: trabajar en nuestros propios proyectos, con libertad para decidir qué hacer, cómo hacerlo y hacia dónde llevar cada producto. Queríamos desarrollar cosas que nos gustaran, experimentar y construir algo a largo plazo.

Con el tiempo, esa intención inicial se ha convertido en una forma de trabajar más definida. Hemos aprendido qué decisiones nos ayudan a avanzar, qué errores conviene evitar y qué procesos necesitamos para que los proyectos no dependan únicamente de la memoria o de la improvisación.

Eso es precisamente lo que queremos compartir en esta serie.

Un estudio indie no tiene por qué ser un caos

Existe una imagen bastante extendida de los estudios pequeños: equipos que improvisan, programan sobre la marcha y deciden qué hacer según les apetece en cada momento. A veces, esa libertad forma parte de su atractivo. El problema aparece cuando se convierte en la única forma de trabajar.

No vamos a fingir que nunca hemos trabajado así. Como cualquier estudio, hemos cometido errores y tomado decisiones que después hemos tenido que revisar. Pero hemos aprendido que la libertad creativa funciona mucho mejor cuando tiene una estructura detrás.

En CraftingBits intentamos mantener una guía clara para cada proyecto. Evaluamos las ideas antes de desarrollarlas, organizamos el trabajo y revisamos cómo evolucionan nuestros productos una vez publicados.

También sabemos que no todos los proyectos merecen el mismo esfuerzo para siempre. Si un producto funciona y sigue teniendo sentido, lo mantenemos y lo mejoramos. Si deja de encajar con nuestros objetivos o no justifica el esfuerzo que requiere, podemos dejarlo en segundo plano.

Saber cuándo continuar y cuándo parar también forma parte del desarrollo. No se trata de trabajar por trabajar, sino de dedicar tiempo y recursos a aquello que realmente merece la pena.

De una idea a un producto

Nuestras ideas no suelen surgir de una reunión formal ni de una sesión de brainstorming programada. Aparecen cuando menos lo esperamos: paseando por la playa, tomando algo en un bar o mientras trabajamos en otro proyecto.

Lo importante no es tanto de dónde viene una idea como lo que hacemos con ella después. Porque tener una idea es fácil; convertirla en un producto útil, viable y mantenerla es otra historia.

Nuestro proceso se puede resumir en tres pasos:

1. Analizar si merece la pena. Antes de empezar a desarrollar, estudiamos la viabilidad de la idea, la competencia, el esfuerzo que requeriría y las posibilidades que tiene. No todas las ideas superan este filtro, y es mejor descartarlas pronto que descubrir demasiado tarde que no tenían sentido.

2. Definir el alcance y construir un MVP. Si la idea nos convence, la ponemos por escrito y delimitamos qué debe incluir la primera versión. Buscamos crear un producto mínimo viable (MVP) que resuelva una necesidad concreta, sin invertir meses en funcionalidades que todavía no sabemos si aportarán valor.

3. Lanzar, aprender y mejorar. Una vez publicado el producto, empieza otra parte del trabajo: observar cómo se utiliza, detectar problemas y decidir qué mejoras merecen la pena. Ampliamos el producto cuando tiene sentido, teniendo en cuenta tanto su evolución como las necesidades de quienes lo utilizan.

Este último punto es fundamental. Escuchar a las personas que utilizan nuestras apps y juegos no es una acción de marketing que hacemos de vez en cuando: es una parte más del desarrollo. Sus comentarios, sus necesidades y la forma en que utilizan el producto nos ayudan a decidir qué hacer después.

El trabajo que no se ve

Si te asomaras a un día cualquiera en CraftingBits, descubrirías que no siempre estamos escribiendo código. De hecho, hay jornadas en las que buena parte del trabajo consiste en hacer cosas que no aparecerán en ninguna captura de pantalla.

Revisamos los proyectos en curso, comprobamos cómo avanzan y valoramos si siguen los plazos previstos. Mantenemos los productos que ya están publicados, solucionamos problemas, respondemos correos y analizamos estadísticas para entender qué está funcionando y qué necesita mejorar.

También dedicamos tiempo a documentar decisiones, organizar tareas y preparar los siguientes pasos. Puede parecer trabajo secundario, sobre todo cuando hay una funcionalidad pendiente que nos gustaría terminar cuanto antes. Sin embargo, es precisamente ese trabajo el que permite avanzar sin perder de vista el conjunto.

Un producto no termina cuando se publica. Necesita mantenimiento, correcciones y decisiones continuas sobre su evolución. Y para que todo eso sea posible, hay que dedicar tiempo a entender su estado actual y a decidir qué merece atención.

El trabajo invisible no es un añadido al desarrollo: es lo que permite que el producto siga funcionando y evolucionando con el tiempo.

Dos errores que nos obligaron a mejorar

Podríamos contar únicamente lo que hacemos bien, pero no sería una imagen completa de cómo trabajamos. Algunos de los cambios más importantes en nuestra forma de desarrollar han surgido de errores propios.

Hay dos ejemplos que ilustran bien este aprendizaje.

• Un repositorio organizado a medias. Hubo una época en la que no todo nuestro trabajo estaba correctamente organizado y respaldado en Git. Un cambio acabó provocando la pérdida de parte de una actualización. Fue una buena forma de entender que el control de versiones no es un detalle técnico que se puede dejar para más adelante: es una parte esencial del trabajo. Desde entonces, mantener el código bajo control de versiones es una regla básica.

• Publicar sin probar lo suficiente. En alguna ocasión lanzamos una funcionalidad sin haberla probado adecuadamente y tuvimos que preparar una actualización urgente para corregir los problemas. Aprendimos que las pruebas no son el último trámite antes de publicar, sino una parte del desarrollo desde el principio. Cuanto antes detectamos un fallo, más fácil suele ser solucionarlo.

No son los únicos errores que hemos cometido, ni serán los últimos. Trabajar en nuestros propios productos implica tomar decisiones, comprobar sus resultados y corregir el rumbo cuando hace falta.

Lo importante no es pretender que todo salga bien a la primera, sino aprender de los errores y convertir ese aprendizaje en una mejora concreta del proceso. Si un problema se repite porque no hemos cambiado nuestra forma de trabajar, entonces no hemos aprendido todo lo que podíamos de él.

Lo que sostiene todo lo demás

Si tuviéramos que resumir nuestra forma de trabajar, la reduciríamos a tres principios: decidir, documentar y construir.

• Decidir antes de construir. Antes de empezar a programar, nos preguntamos si el proyecto tiene sentido, si encaja con nuestros objetivos y si merece el tiempo que requiere. También decidimos qué funcionalidades son necesarias y cuáles pueden esperar. No todo lo que se puede hacer merece hacerse.

• Documentar lo importante. Las decisiones que condicionan un proyecto deben quedar por escrito. No queremos depender de que alguien recuerde por qué se eligió una solución, qué hace una funcionalidad o cómo está organizada una parte de la aplicación. En Antes del código: cómo planificamos una app antes de programar explicamos con más detalle cómo abordamos esta fase.

• Construir pensando en el futuro. No basta con conseguir que algo funcione hoy. También debemos procurar que el código se pueda entender, modificar y mantener dentro de un año. Eso implica elegir soluciones razonables, probar los cambios y dejar la información necesaria para continuar el trabajo sin tener que reconstruir todo el contexto desde cero.

Sobre el papel, estos principios parecen sencillos. Lo difícil es mantenerlos cuando hay prisa, una funcionalidad que queremos publicar o un problema que necesitamos resolver cuanto antes.

Añadir una implementación puede ser relativamente rápido. Documentarla, probarla y comprobar que encaja con el resto del proyecto requiere más atención y, a veces, resulta menos gratificante. Pero es precisamente esa parte la que evita que cada mejora complique un poco más la siguiente.

Queremos que nuestros productos puedan evolucionar sin depender de que recordemos cada detalle de cada pantalla, función o aplicación. Para conseguirlo, necesitamos procesos que nos ayuden a trabajar con orden, incluso cuando las cosas no salen como esperábamos.

Lo que viene en esta serie

Este es el primer capítulo de El estudio por dentro, una serie en la que queremos explicar cómo organizamos el trabajo y qué hay detrás de nuestros productos.

En los próximos artículos profundizaremos en algunos aspectos concretos:

2. Núcleo, arranque y memoria: cómo organizamos nuestros proyectos y gestionamos su estructura.
3. Nuestra caja de herramientas: qué tecnologías y herramientas utilizamos, y por qué.
4. Rituales y cadencia: cómo organizamos el trabajo y mantenemos el ritmo sin llenar la agenda de reuniones.
5. Comunicar sin humo: cómo gestionamos las expectativas, los plazos y la decisión de decir «no» cuando un proyecto no encaja.

Algunas de estas cuestiones ya las hemos abordado desde otras perspectivas. Por ejemplo, en WordPress y Elementor: la opción más usada no siempre es la mejor explicamos por qué elegir una tecnología por costumbre no siempre es la mejor decisión. En esta serie veremos cómo ese mismo criterio se aplica a nuestra organización y a nuestro trabajo diario.

No hay magia ni una herramienta secreta detrás de CraftingBits. Hay ideas, decisiones, pruebas, errores y bastante trabajo que no siempre se ve desde fuera.

Nuestra forma de entender el desarrollo parte de una convicción: el trabajo que no se ve influye directamente en el resultado que sí se ve. Trabajar bien no consiste únicamente en avanzar rápido, sino en construir productos que tengan sentido, que podamos mantener y que sigan evolucionando con el tiempo.

Esperamos que esta serie te ayude a conocer mejor cómo trabajamos, por qué tomamos determinadas decisiones y cómo han ido naciendo las apps y los juegos que hemos desarrollado en CraftingBits.