Inothy - Todo lo que aprendí construyendo mi primera app real (con sus errores incluidos)

Hace unos años, junto a un amigo, decidimos montar una startup: una plataforma donde los estudiantes pudieran comprar y vender apuntes universitarios. La idea era sencilla, pero ambiciosa. Y lo más desafiante: yo era el único desarrollador.

Ya llevaba un tiempo aprendiendo por mi cuenta, pero nunca me había enfrentado a un proyecto real desde cero, con usuarios, pagos, arquitectura… y sin nadie que me dijera cómo hacerlo. Spoiler: cometí muchos errores, pero aprendí muchísimo más.

⚙️ Hacerlo todo, decidirlo todo

Inothy no era una práctica ni un ejercicio de un curso. Era una app real. Y eso implicaba muchas cosas:

Registro e inicio de sesión
Subida y descarga de archivos
Panel de usuario
Buscador con filtros por carrera, universidad, etc.
Pasarela de pago
Diseño, despliegue, estructura, seguridad…

No tenía stack impuesto ni guía técnica. Todo lo decidí yo, con lo que sabía en ese momento y lo que fui aprendiendo por el camino.

🧠 Decisiones técnicas (y cómo fueron evolucionando)

🔐 Autenticación con Firebase

Para el sistema de login usé Firebase Auth, por su aparente simplicidad y porque no tenía que montar un backend desde el primer momento. Sin embargo, pronto me di cuenta de que no ofrecía soporte real para server-side rendering, algo que me interesaba por motivos de rendimiento y control. Dedicar tiempo a intentar encajar Firebase con SSR fue frustrante, y si hoy tuviera que elegir, optaría por una solución más flexible y controlable desde backend.

🧮 Tipado, base de datos y un cambio de mentalidad

Durante las primeras fases del proyecto, todo estaba hecho con JavaScript puro y Firebase como base de datos. La estructura de los datos era caótica, sin esquema, sin validación… simplemente iba guardando “lo que funcionaba”.

A medida que el proyecto crecía, me di cuenta de que el tipado débil y la falta de estructura me estaban frenando. Fue entonces cuando tomé una decisión clave: migré todo a TypeScript y MongoDB con Prisma.

Tuve que aprender TypeScript desde cero, pero el cambio fue radical. Gané seguridad, claridad y una forma de pensar más robusta. Prisma me ayudó mucho en ese momento, aunque hoy, con más experiencia, optaría por Drizzle, que me parece más transparente y menos “mágico”.

🎨 Estilos con Panda CSS

Para los estilos decidí usar Panda CSS, porque se parecía más a CSS puro, que era lo que mejor dominaba entonces. Fue una elección muy cómoda en ese momento, y me permitió trabajar con un sistema de estilos claro, con tokens y buenas prácticas. Pero con el tiempo me di cuenta de que fue un error técnico: Panda aún no estaba en versión estable, y tuve que lidiar con varios bugs, falta de documentación y cambios que rompían cosas. Hoy no lo elegiría para un proyecto serio en producción, pero en su momento me permitió avanzar y aprender.

🧱 Arquitectura y estructura del código

Al principio, todo el proyecto vivía en el mismo repositorio, sin separación clara entre frontend y backend. Eso funcionó durante un tiempo, pero en cuanto el código creció, se volvió inmanejable.

Decidí reorganizar todo usando Turborepo y separando bien las capas del proyecto. No fue fácil ni inmediato, pero aprender a estructurar el código como si fuera un proyecto serio de verdad fue uno de los grandes saltos de calidad del desarrollo.

🧾 Formularios que no duelen

Hacer formularios es peor que un dolor de muelas, pero fue una de las cosas a las que más mimo le puse en Inothy. Y me siento especialmente orgulloso del resultado.

Implementé formularios multi-paso con animaciones suaves, donde cada paso está bien explicado para que el usuario nunca se pierda. Uno de ellos aparece en la demo porque realmente creo que es una de las partes más cuidadas de la experiencia.

También me aseguré de que fueran totalmente accesibles con teclado, algo que muchos proyectos siguen pasando por alto. La experiencia de usuario en los formularios de Inothy es, sinceramente, un 10/10.

🚧 Lo difícil no fue el código

Pensaba que lo duro sería la parte técnica, pero lo que más me costó fue la incertidumbre constante: no tener validación externa, no saber si lo estaba haciendo bien, no saber cuánto tardarían las cosas.

Estimé mal el tiempo, me perdí en detalles, me frustré con problemas absurdos y reescribí partes enteras del proyecto varias veces. Pero eso también fue lo que más me enseñó.

🧠 Más allá del código

Inothy también me enseñó cosas que no tienen que ver directamente con el desarrollo, pero que hoy valoro mucho.

Mirando atrás, creo que nos obsesionamos con tener un producto perfecto antes de sacarlo al mercado. Perdimos tiempo afinando detalles técnicos y visuales, cuando podríamos haber salido antes con una versión más sencilla para validar la idea.

Aprendí que lo perfecto es enemigo de lo útil, y que en un producto real hay que saber priorizar, enfocar y lanzar. Hoy tengo claro que no todo lo técnico es urgente, y no todo lo urgente es técnico. Esa mentalidad me acompaña en todos mis proyectos desde entonces.

💡 Lo que aprendí (de verdad)

Construir Inothy fue mi mejor escuela. Me enfrenté a todo: bugs, decisiones difíciles, problemas técnicos, migraciones, pagos reales, usuarios… Y aunque la empresa no salió adelante, el proyecto sí lo terminé, y eso me demostró que podía enfrentarme a un desarrollo completo de verdad.

Gracias a Inothy:

Aprendí a valorar el tipado y la arquitectura desde el inicio
Entendí por qué no todo lo que parece fácil lo es a medio plazo
Empecé a tener criterio para elegir herramientas, no solo seguir modas
Me acostumbré a resolver problemas solo y aprender rápido cuando no hay nadie más
Y sobre todo, entendí que construir producto va más allá del código

🌍 Ponerlo en el mundo

Inothy no se quedó en local: llegó a estar desplegado y funcionando. Y aunque no fue la parte más vistosa, el despliegue fue uno de los aspectos donde más aprendí.

Hasta entonces pensaba que desplegar una web era simplemente subirla “a algún sitio”, pero pronto descubrí que no era tan simple. Había que pensar en rendimiento, seguridad, actualizaciones, costes, backups, incluso en qué pasaba si algo fallaba a las 3 de la mañana.

Tuve que tomar decisiones sin tener toda la información, cambiar de plataforma a mitad de camino, automatizar procesos y lidiar con muchas cosas que nunca antes había considerado. Fue ahí donde empecé a entender que desplegar no es el final del desarrollo, sino otra parte del diseño del producto.

Hoy en día sé muchísimo más sobre esta parte, pero Inothy fue mi primera lección real sobre lo que implica poner un proyecto en manos de usuarios reales.

🧑‍💻 Hoy

Sigo teniendo el código, y aunque hay cosas que hoy haría diferente, me sigue recordando todo lo que aprendí por el camino. Inothy no fue un proyecto perfecto, pero fue mi primer proyecto real, y el que me dio confianza para seguir creciendo como desarrollador.

📦 El código completo está disponible en GitHub: github.com/hostyn/inothy

🎥 A continuación puedes ver una demo en vídeo de la aplicación. No he hecho un despliegue funcional porque implicaría usar un bucket de Google Cloud, lo que supone costes que prefiero evitar. Pero la demo refleja bien lo que construí.