Cómo organizamos un proyecto en Reveled

Hay agencias que tienen metodologías con nombre propio, diagramas de cuatro fases y herramientas de gestión con 40 columnas. Nosotros tenemos algo más útil: un flujo que funciona de verdad, que no genera fricción y que escala tanto para un proyecto de dos semanas como para uno de tres meses.

Aquí está, sin adornos.

El cerebro del sistema: Obsidian

Todo empieza en Obsidian. No en un gestor de proyectos, no en un tablero Kanban, no en una hoja de cálculo. En Obsidian.

La razón es simple: soy dueño de los archivos. Son ficheros Markdown en local, en mi máquina, sin depender de que ninguna empresa decida cambiar su modelo de precios o deprecar una función. Los puedo abrir con cualquier editor, versionar con Git, buscar con cualquier herramienta, y van a seguir siendo legibles dentro de diez años.

Cada cliente tiene su nota. Cada proyecto tiene su nota. Y esas notas están conectadas — el cliente enlaza con el proyecto, el proyecto enlaza con las decisiones que se tomaron, con los recursos, con los accesos, con las conversaciones importantes. No hay que recordar dónde está nada porque todo está enlazado.

Lo que me parece más potente es la integración con NotebookLM: puedo cargar las notas de un proyecto y pedirle que genere un resumen, que busque contradicciones en el brief, que cree preguntas de descubrimiento para el cliente. El conocimiento que acumulo en Obsidian se convierte en materia prima para trabajar con IA de forma útil, no genérica.

Las tareas: Todoist con automatizaciones

Las notas de Obsidian son el contexto. Las tareas concretas viven en Todoist.

No lo uso como una lista de pendientes. Lo uso con proyectos estructurados, fechas de entrega reales y automatizaciones que se encargan de la parte repetitiva. Cuando arranca un proyecto nuevo, hay un conjunto de tareas que siempre aparecen: brief inicial, propuesta, revisión de diseño, revisión de código, deploy, seguimiento post-lanzamiento. Eso no lo creo cada vez a mano — hay plantillas y automatizaciones que lo generan solo.

Lo que me importa de Todoist no es que sea bonito. Es que tiene una API buena, que se integra con casi todo y que no me pone obstáculos cuando quiero hacer algo que no estaba en el manual.

La terminal como entorno de trabajo

El día a día de desarrollo ocurre casi todo en terminal. Git, Claude Code, WP-CLI cuando toca WordPress, despliegues vía SSH, gestión de servidores. No porque sea más difícil, sino porque es más rápido, más reproducible y más fácil de automatizar.

Trabajar desde terminal con Claude Code significa que puedo pedirle que implemente una funcionalidad, revise el código, detecte problemas de rendimiento o escriba tests, todo sin salir del proyecto. El contexto no se pierde, no hay que copiar y pegar entre ventanas, y el historial de lo que se hizo queda en los commits.

Eso cambia la forma de trabajar. Lo que antes era una tarea para una tarde, ahora es una tarea para una hora. Y esa diferencia la nota el cliente en el presupuesto y en el tiempo de entrega.

Cuándo entra Notion — y cuándo no

Para proyectos en solitario, Obsidian más que suficiente. Pero cuando trabajo con un equipo o cuando hay un cliente que necesita visibilidad sobre el progreso, usamos Notion.

El plan gratuito da para mucho más de lo que la mayoría necesita. Para proyectos grandes, para equipos que se coordinan en múltiples frentes, Notion funciona bien. He trabajado invitado en Notions de organizaciones con equipos de veinte personas y el sistema aguanta. Es la herramienta de colaboración que más sentido tiene cuando hay más de dos personas tocando el mismo proyecto.

Lo que no uso es Notion para trabajo personal. Ahí la fricción sube: todo vive en la nube de otra empresa, la búsqueda no es tan rápida, y el modelo de datos es más rígido de lo que parece a primera vista.

Por qué ClickUp no

Lo he probado. Tiene todo lo que cualquier metodología de gestión de proyectos podría pedir: vistas, automatizaciones, dashboards, integraciones. El problema es que tiene demasiado. La curva de entrada para hacer algo simple es desproporcionada, las guías son confusas y el sistema tiene tanta opinión sobre cómo debes trabajar que termina siendo la herramienta quien manda, no tú.

Para lo que hacemos en Reveled, esa fricción no tiene ningún retorno. La fluidez importa. Cuantos menos obstáculos entre la idea y la ejecución, mejor.

Cómo fluye un proyecto de principio a fin

El flujo real, sin adornos:

Cuando alguien contacta, lo primero es entender si podemos ayudarle de verdad. Hay proyectos que no son para Reveled — si alguien busca velocidad por encima de calidad, le decimos que no somos la opción y le orientamos hacia algo que le encaje mejor. Si hay encaje, en 48 horas hay una propuesta. Sin reuniones de “conocimiento” de 90 minutos.

La propuesta describe exactamente qué se hace, qué no está incluido, cuánto cuesta y cuándo estará listo. Dos rondas de revisiones incluidas. La tercera se factura aparte, sin sorpresas.

El diseño empieza por la estructura, no por Figma. Wireframes en texto o esquemas simples hasta que la arquitectura está clara. Es más fácil cambiar un esquema que un mockup de alta fidelidad. Una vez aprobada la estructura, diseñamos y no avanzamos a desarrollo hasta que el diseño está validado.

El código vive en GitHub desde el primer commit. El stack queda definido en la propuesta y no cambia a mitad del proyecto. El cliente tiene acceso a un entorno de preview durante el desarrollo — no esperamos al final para mostrar resultados. El deploy es automático: cada push a la rama principal actualiza el servidor.

El lanzamiento no es el final. Quince días de soporte post-lanzamiento incluidos. Repositorio, documentación básica y la posibilidad de retomar en el futuro si hace falta.

La herramienta correcta no existe — el sistema sí

Lo que hace que este flujo funcione no es ninguna de las herramientas por separado. Es que cada una tiene un rol claro y no se solapan. Obsidian es el contexto. Todoist son las tareas. La terminal es la ejecución. Notion es la colaboración cuando hace falta.

Cuando una herramienta empieza a generar más fricción que valor, la cambiamos. Sin apego, sin miedo a perder la “inversión” en aprender algo. El objetivo no es dominar herramientas — es entregar proyectos que funcionen.

Si tienes curiosidad sobre cómo aplicaría este flujo a tu proyecto, puedes ver algunos resultados en el portafolio o pasarte por consultoría para hablarlo sin compromiso.

---

Este post va a seguir creciendo. El flujo evoluciona, las herramientas cambian, y hay partes del proceso que merecen su propio artículo. Escríbenos si hay algo concreto que quieras que expliquemos.