1. Introducción

En Nobuzen nos tomamos en serio cada proyecto que llega a nuestras manos. Y cuando decimos en serio, nos referimos también a respetar al máximo la confidencialidad con la que algunos clientes nos confían sus ideas. En este caso concreto, firmamos un NDA que nos impide compartir detalles clave del producto o del negocio… pero eso no significa que no podamos hablar —y con orgullo— de cómo lo estamos desarrollando.

Porque al final, lo que cuenta es cómo se hacen las cosas. La solidez técnica, la elección de tecnologías bien pensadas, una arquitectura que respire escalabilidad desde sus cimientos, y una gestión de proyecto que no se deja nada al azar. Sabemos que, si nos estás leyendo, probablemente te interesa más el “cómo lo hacemos” que el “para quién lo hacemos”. Y justo eso es lo que venimos a contarte.

Este desarrollo, que aún está en marcha, nos está permitiendo aplicar al 100% nuestra filosofía: tecnología moderna, procesos bien engrasados y decisiones técnicas que no se toman “porque sí”, sino porque responden a una visión estratégica. Vamos a contarte, sin desvelar lo que no podemos, todo lo que hay detrás de un producto digital serio y con ambición.

2. Arquitectura Frontend

Cuando arrancamos este proyecto, sabíamos que el frontend no podía ser “otro más”. Iba a crecer, eso estaba claro desde el principio. Así que lo primero fue buscar algo que ya nos hubiera funcionado antes, que pudiéramos escalar sin sufrir. Y ahí Angular con Ionic encajó como un guante.

Angular nos da estructura, orden, claridad. Y con Ionic encima, conseguimos que todo esto funcione igual de bien en móvil que en escritorio. Es algo que valoramos mucho porque no nos gusta escribir el doble si no hace falta —y al cliente tampoco, claro—.

A mitad del primer sprint, ya nos dimos cuenta de que gestionar los estados a mano iba a ser un caos a medio plazo. Así que metimos NgRx. No es ligero, pero vale cada línea de código. Nos permite ver qué está pasando en cada momento, quién cambió qué y por qué. Y cuando algo falla (porque siempre hay algo que falla), podemos seguir el rastro sin volvernos locos.

En cuanto a cómo organizamos el código… bueno, aquí hicimos algo que venimos aplicando últimamente y nos funciona muy bien: componentes standalone, cada uno con su carpeta, sus hijos, su lógica. Jerárquico. Modular. Limpio. Lo bueno es que si mañana alguien nuevo entra al equipo, entiende todo en una mañana. Nada de estructuras laberínticas que solo entiende quien las creó.

Es una base que nos permite construir rápido, pero sin perder el control. Y lo mejor: si el cliente pide algo nuevo dentro de seis meses, no vamos a tener que rehacer medio proyecto.

3. Arquitectura Backend

Aquí no nos anduvimos con rodeos: el backend tenía que ser rápido, limpio y fácil de mantener. No solo por nosotros, sino pensando en el futuro del proyecto. Así que fuimos directos a lo que ya sabemos que funciona: Python con FastAPI.

FastAPI nos ha dado más de una alegría en otros desarrollos. Es ligero, moderno, y lo mejor de todo: asíncrono. Cuando tienes que manejar peticiones de aquí y de allá al mismo tiempo, se nota. No es la típica solución sobrecargada que te obliga a escribir tres veces más de lo necesario. Con FastAPI puedes ir al grano y dejarlo todo bien estructurado desde el principio.

Y hablando de estructura… aquí aplicamos algo que en su día nos simplificó mucho la vida: Scream Architecture. Es un enfoque que, dicho mal y pronto, hace que cuando alguien abre el proyecto, lo primero que vea sea el dominio. Lo que realmente importa. Lo esencial. Nada de perderse entre carpetas con nombres genéricos o mezclas raras de lógica con infraestructura.

Esto nos ha permitido tener el código organizado de tal forma que cualquiera —del equipo o nuevo— pueda entender qué hace cada parte sin tener que leerse todo el proyecto. Y eso, cuando llevas unas cuantas funcionalidades encima, es oro puro.

Además, al estar todo tan bien separado, añadir nuevas rutas, adaptar lógica o incluso cambiar de base de datos si hiciera falta… no nos supondría un drama. El backend está montado para durar, no solo para funcionar.

4. Gestión y Diseño de Base de Datos

Con la base de datos no hay lugar para parches. O la diseñas bien desde el minuto uno, o luego cada cambio es una pesadilla. Y en este proyecto, como sabíamos que la cosa iba a escalar, decidimos ir a por todas desde el principio.

Tiramos de Supabase, que trabaja sobre PostgreSQL, y la verdad… ha sido un acierto. Nos da lo que necesitamos: fiabilidad, rendimiento, autenticación integrada y todo con una curva de aprendizaje razonable. Pero más allá de la herramienta, lo que realmente marca la diferencia es cómo montamos la estructura.

Normalizamos la base hasta la quinta forma normal. Sí, suena académico, pero lo hicimos por pura necesidad. Queríamos que los datos estuvieran limpios, bien relacionados y sin redundancias raras. No nos valía eso de “lo dejamos así de momento y luego ya lo arreglamos”. Porque ese luego nunca llega, y después estás atrapado entre duplicados, joins imposibles y bugs que aparecen de la nada.

Diseñamos todo con lógica relacional clara. Las tablas se comunican lo justo y necesario, y cada campo tiene su razón de ser. De hecho, cuando empezamos a probar con más volumen de datos, el rendimiento se mantuvo estable sin que tuviéramos que tocar prácticamente nada. Esas son las cosas que te alegran el día.

Y lo mejor: si mañana el cliente quiere añadir una nueva funcionalidad o cambiar el flujo de datos, sabemos que la base puede con ello sin romperse en mil pedazos.

5. Enfoque en UI/UX

Desde el primer día, sabíamos que este proyecto no podía limitarse a “funcionar bien”. Tenía que sentirse bien. Y para eso, la experiencia de usuario no es un complemento, es el núcleo. Así que antes de escribir ni una línea de código, nos sentamos —literalmente— a trazar cómo se iba a mover la gente dentro de la app.

Arrancamos con wireframes rápidos, papel y lápiz al principio (porque a veces lo más simple es lo que mejor funciona) y luego pasamos a algo más formal con Figma. Lo bueno de usar Figma es que puedes ir desde lo más básico hasta prototipos de alta fidelidad sin cambiar de herramienta, y eso nos dio mucha agilidad.

También montamos varios flujogramas de navegación para entender qué caminos iba a seguir un usuario desde que entra hasta que completa una acción importante. Más de una vez, al ponerlo en limpio, vimos que estábamos complicando algo que podía resolverse con un clic menos. Así que iteramos. Y volvimos a iterar. Y sí, a veces nos tocó volver a la pizarra.

Otro paso clave fue el trabajo con user personas. Creamos perfiles detallados que nos ayudaron a tomar decisiones más realistas: no diseñamos para “el usuario promedio”, sino para alguien con necesidades, frustraciones y objetivos muy concretos.

Y como no podía ser de otra forma, construimos un design system propio desde cero. Colores, tipografías, botones, inputs… todo alineado. Así, cada nueva pantalla se arma en menos tiempo y con coherencia total. Porque si el diseño empieza a desentonar, el usuario lo nota —aunque no sepa explicarlo—.

Este enfoque nos ha ahorrado dolores de cabeza en desarrollo, y sobre todo, nos ha permitido construir una interfaz donde el usuario no se pierde, no se frustra, y entiende lo que tiene que hacer sin que nadie se lo explique.

6. Estrategia de Testing

Una cosa la tenemos clara en Nobuzen: si no se prueba, no está hecho. Por muy buena pinta que tenga el código, el testing no es opcional. Nos ha pasado más de una vez —en proyectos antiguos o que heredamos— toparnos con funcionalidades que “funcionaban… hasta que no”. Así que en este proyecto no quisimos dejar ni un cabo suelto.

Desde el principio metimos test unitarios en las partes críticas. Cada módulo, cada lógica de negocio, validada desde el momento en que se escribía. Eso nos permitió ir avanzando con seguridad. Que sí, lleva algo más de tiempo al principio, pero cuando llega el momento de refactorizar o escalar, te ahorras tres veces más de lo que invertiste.

El plan de testing lo estructuramos en fases muy marcadas:

Un detalle que marca la diferencia: los testcases los probó gente que no estuvo en el desarrollo. Porque cuando tú construyes algo, es fácil que se te escape lo evidente. En cambio, alguien externo entra sin prejuicios, sin saber “lo que debería pasar”… y eso nos dio insights buenísimos para pulir la experiencia final.

Gracias a todo este proceso, llegamos a cada fase con menos errores, más confianza en el producto, y un equipo más relajado (lo cual no es poco).

7. Gestión de proyectos y metodología

A estas alturas, ya no concebimos un proyecto sin una buena organización desde el minuto cero. Por experiencia, sabemos que cuando los tiempos no se controlan, las tareas se acumulan, y las decisiones se toman “por intuición”… el caos no tarda en aparecer. Así que, como hacemos siempre en Nobuzen, metimos estructura desde el principio, pero sin volvernos rígidos.

Optamos por una planificación basada en Kanban, que nos da flexibilidad pero sin perder de vista el control. Nos permite ver, en tiempo real, qué está en marcha, qué está bloqueado y qué ya está cerrado. Cada columna del tablero cuenta una historia, y más de una vez nos ha servido para detectar cuellos de botella o tareas que parecían pequeñas y se estaban eternizando.

Dividimos el proyecto por épicas y funcionalidades, con tareas bien desglosadas para no perdernos en ambigüedades. Cada funcionalidad tiene su tiempo estimado, sus dependencias y su prioridad marcada. Y sí, a veces hay que reajustar sobre la marcha, pero justo por eso llevamos un seguimiento de horas, plazos y porcentaje de avance. No se trata de ser obsesivos, se trata de saber dónde estamos parados en cada momento y poder tomar decisiones con datos reales, no a ojo.

Algo que también nos funciona muy bien es el registro de dependencias técnicas. Porque cuando una tarea se atasca, muchas veces no es por el código, sino porque está esperando algo más. Tener eso bien trazado nos ha ahorrado más de una reunión de “¿por qué esto todavía no está?”

En resumen: con la metodología que usamos, no solo llegamos a tiempo, sino que lo hacemos con control, visibilidad y sin quemar al equipo por el camino.

8. Cierre y ventajas competitivas

No vamos a maquillarlo: este proyecto nos está poniendo a prueba, y justo por eso nos está encantando. No por lo difícil, sino porque nos obliga a aplicar todo lo que hemos aprendido estos años. Elegir bien la tecnología, organizarnos sin pisarnos, pensar en el usuario desde el primer día, dejarlo todo bien atado para lo que venga después… Y todo eso, sin poder contar mucho hacia fuera.

No podemos hablar de lo que hace la app, ni de para quién la estamos construyendo, pero sí podemos decir esto: es el tipo de proyecto para el que montamos Nobuzen. Donde el cliente necesita algo sólido, con futuro, que pueda crecer sin romperse. Donde se espera calidad técnica, sí, pero también criterio. Porque a veces hay que saber decir “esto así no va a escalar”, o “por aquí no es, aunque parezca lo más rápido”.

Y ese es uno de nuestros puntos fuertes: no nos limitamos a entregar lo que se nos pide, sino que lo planteamos con visión. Porque sabemos que lo barato se paga caro, y que si un proyecto no está bien planteado, al final hay que rehacerlo. Nosotros preferimos hacerlo bien a la primera, aunque lleve un poco más.

A día de hoy, tenemos una arquitectura que se mantiene sola, un código que cualquiera puede retomar sin llorar, y un equipo que sabe lo que hace y por qué lo hace. Y eso, para nosotros, es valor real.