Casi dos años de Deeditt: arquitectura, decisiones y desafíos tras haber emprendido este viaje

Una infraestructura sólida no garantiza usuarios, una buena idea tampoco, pero compartir el camino —eso sí cambia cosas.

Por qué decidí construir Deeditt

Digamos que me llevó un año planear y prepararme mentalmente que estaria haciendo esto por mucho tiempo, otro año para desarrollar un backend, un frontend, preparar servidores y algo basico de seguridad y un año más empezar a probar la idea de forma real, con usuarios reales.

Llevo varios años trabajando como desarrollador de software, a lo largo del tiempo he construido productos desde cero, escalado infraestructuras, liderado equipos y solucionado crisis técnicas, y es que durante todo este tiempo siempre necesité ayuda, y cuando estuve en medio de esas entrevistas, las personas decían mentirillas, porque no hay forma tangible de probar lo contrario. Pero en todo ese camino hubo algo que siempre me incomodó: la falta de espacios donde compartir el proceso real, no solo el resultado final, solía decirme, "Si Deeditt existiera, esto no pasaría".

Así fue como nació Deeditt, una red social distinta. Mientras plataformas como LinkedIn celebran logros espectaculares y Medium premia los artículos que se ajustan al algoritmo, yo quería algo más honesto, un lugar donde pudiera documentarse el camino, con todos sus errores, cambios, ajustes y momentos de duda.

La idea de Deeditt surgió de una necesidad personal: quería leer más sobre decisiones difíciles y menos sobre éxitos brillantes, tener mejor idea de las experiencias reales de las personas, así que decidí construirlo yo mismo, porque definitivamente es mejor aprender desde la experiencia de alguien más que desde su logro final donde suelen decir "Aprendi a andar en patines, estos son los 5 consejos que te enseñaran a ir más rapido".

Empecé por una app móvil, quizás una mala decisión

Cuando imaginé Deeditt, lo vi como una red social y pensé automáticamente en una app móvil, me pareció lo lógico, así que empecé a construir en React Native, una tecnología que ya conocía bien y que me permitía mantener una base de código única para iOS y Android.

Con el tiempo me di cuenta de que también necesitaba una versión web, muchas personas escriben desde el navegador y, además, no todos quieren instalar una app para probar algo nuevo. El contenido largo y la reflexión pausada tienen mejor lugar en una interfaz de escritorio, no fue un error empezar por móvil, pero probablemente habría sido más estratégico comenzar por la web.

Ahora estoy trabajando en esa versión, aprovechando mucho del backend y diseño que ya tengo, afortunadamente mi arquitectura me permite extender fácilmente sin tener que rehacerlo todo.

Mi stack y cómo lo mantengo

Desde el principio me propuse que todo el sistema pudiera mantenerse sin demasiada intervención, automatización, bajo costo y control fueron mis principios clave, básicamente mucho de lo que los proveedores de servicios en la nube hacen por ti, yo lo decidí hacer por mi cuenta, el resultado es muchas horas de trabajo, pero un gasto mensual para mantener la infraestructura sumamente bajo.

Uso Docker Hub como base, con GitHub Actions para CI/CD, todo corre en VPS que gestiono con Ansible y comandos escritos en Make. El monitoreo lo tengo con Prometheus, New Relic y Loki, y las alertas me llegan por Slack, así me entero de cualquier caída o anomalía en minutos.

Dividí el backend en microservicios: usuarios, publicaciones, notificaciones, media, mensajes, etc., cada uno tiene su propia base de datos y lógica independiente, algunos están escritos en Node.js, otros en Go o Python, dependiendo del tipo de procesamiento que necesitaban, así evito cuellos de botella y puedo actualizar cada uno sin afectar a los demás.

Servicios que se ejecutan en background con Prefect y comunicaciones asincronas entre aplicaciones usando BullMQ y Redis.

Cómo se comunican los servicios

Uno de los retos que más tiempo me tomó fue diseñar cómo se iban a comunicar los servicios, y entre HTTP más Docker Swarm para orquestación, y una red interna donde solo se exponen los endpoints necesarios, esta decisión ayuda a reducir riesgos de seguridad y mantiene todo más limpio.

Tuve que escribir varias reglas personalizadas para asegurar que la conexión entre contenedores fuera estable, nada complejo, pero sí muy delicado, aquí es donde más valoré haber tenido experiencia previa con sistemas distribuidos, pude haber empezado usando métodos más sofisticados, pero mantenerlos hubiese sido un dolor de cabeza que busqué evitar en esta etapa. Un punto de entrada para los requests que se convirtió en un proxy de redireccion de trafico entre microservicios, básico pero funcional.

Releases y rollback sin drama

Trabajo con ramas dev, staging y producción, como mi presupuesto es limitado, mi sandbox es muy limitado y comparte algunos recursos con producción más una mezcla local, eso me obliga a ser cuidadoso, pero funciona.

Cuando libero una nueva versión, todo queda taggeado tanto en GitHub como en Docker Hub, si algo falla, simplemente hago rollback apuntando a una imagen anterior, no es elegante, pero es eficiente, en menos de una hora puedo hacer todo el proceso para todos los microservicios sin problema.

Lo que aprendí con el tiempo

Al principio implementé sistemas complejos: un algoritmo de puntaje con muchas reglas, un sistema de popularidad basado en múltiples factores, pero con el tiempo me di cuenta de que había sobre-diseñado cosas que en realidad necesitaban ser simples.

También construí dashboards muy detallados en Grafana, quería tener métricas de todo, y las tengo, pero la verdad es que muchas veces no las necesito, en una etapa inicial eso fue más un capricho técnico que una necesidad real.

Si volviera atrás, simplificaría, no todo necesita ser perfecto desde el día uno, a veces, lo “suficientemente bueno” es justo lo que hace falta.

La idea de los "Journeys"

Una de las cosas más especiales que tiene Deeditt, al menos desde mi perspectiva, son los "Journeys": agrupaciones de publicaciones que permiten contar una historia a lo largo del tiempo.

No es solo publicar un logro, sino mostrar cómo llegaste hasta ahí, qué decisiones tomaste, qué cosas salieron mal, cuánto tiempo te tomó. Eso, para mí, tiene más valor que cualquier artículo brillante sin contexto.

Y como muchas cosas que hacemos en la vida, siempre estamos en más de una sola cosa, yo soy un ejemplo claro, porque mientras escribo sobre este proceso de desarrollo de Deeditt, también escribo sobre mi hijo, mis aprendizajes en mar abierto, algunos problemas de salud y otros temas, cada cosa separada, sin necesidad de compartir muchos detalles personales, sino más una visión general de ese momento que estoy atravesando.

El verdadero reto: construir comunidad

Todo lo técnico funciona, y sin embargo, ahí no está el mayor desafío, lo difícil es que alguien lo use, lo difícil es construir comunidad.

Me reincorporé a las redes sociales para compartir lo que estoy haciendo, aprendí (o estoy aprendiendo) sobre marketing, copywriting, contenido, y aunque no soy experto en eso, sé que es parte del juego.

En Medium, por ejemplo, vi cómo muchos posts bien escritos no tienen visibilidad si no encajan en lo que el algoritmo quiere, en LinkedIn todo es perfecto, todos son geniales, en Deeditt quiero todo lo contrario: lo imperfecto, lo real, lo que normalmente no se cuenta.

Lo que me ha enseñado el feedback

La gente a menudo me dice que la idea es buena, que les gusta, que tiene sentido y que algo así es necesario, pero no siempre la usan, y ahí hay una gran lección: lo que alguien dice que haría no siempre coincide con lo que hace.

Estoy usando ese comportamiento para ajustar la experiencia, pero lo hago con calma, quiero escuchar más de lo que asumo, y estoy preparado para cambiar lo que sea necesario.

Cómo planeo crecer (sin presupuesto)

Mi estrategia de crecimiento es orgánica, primero compartir contenido real, segundo conectar con personas afines, tercero involucrarme en comunidades donde este tipo de ideas pueden tener impacto, y finalmente, si el producto madura, invertir en publicidad pagada. Te preguntarás muchas cosas después de esto, pero Deeditt me cuesta mantenerlo en este momento apenas unos 150 USD mensuales, y créeme que hay más complejidad de lo que he mencionado en este artículo, y es que con apenas pocos usuarios no se requiere mucho, pero al menos da para unos cientos de usuarios más antes de escalar.

Es más lento, sí, pero es más auténtico, y me da espacio para ajustar, a lo largo de los años he tenido muchas ideas que he abandonado, luego alguien inicia algo similar y las convierte en un producto redituable, entonces tengo buenas ideas, pero soy muy malo vendiéndolas o no dedico suficiente tiempo y paciencia para verlas crecer.

Para cerrar

Como desarrollador, siempre me fue fácil comunicarme con sistemas, pero no con personas, crear Deeditt me ha enseñado mucho sobre lenguaje, empatía y claridad.

Y eso me gusta, es parte de mi propio crecimiento, no esperaba que una plataforma que construí para otros también me ayudara a mí.

Sigo trabajando en Deeditt, sigo escribiendo sobre todo este proceso, lo hago porque creo que tiene sentido, aunque el crecimiento sea lento, lo hago porque quiero que exista un lugar donde podamos mostrar nuestros procesos, sin miedo y sin maquillaje.

Si tienés una idea, empieza, no esperes a que sea perfecta, no esperes a tener todo claro, lo irás resolviendo, y lo que hoy te parece una gran solución, puede que mañana ya no lo sea, está bien, eso es construir.

Happy coding! :D

Photo by La-Rel Easter on Unsplash

Written with StackEdit.