Última actualización: 22 de enero de 2026

Sistema básico de archivos para proyectos digitales

Un sistema básico de archivos para proyectos digitales no es “orden bonito”: es velocidad. Te ahorra horas buscando recursos, evita duplicados, reduce errores de entregables y hace que cualquier persona (tú o un colaborador) entienda el proyecto en 60 segundos.

Tabla de contenidos

• Definición: “sistema de archivos” (en proyectos reales)
• Errores típicos que te cuestan tiempo (y dinero)
• La estructura mínima recomendada (plantilla)
• Naming conventions que sí funcionan
• Versionado simple (sin volverte loco)
• Flujo de trabajo: cómo usarlo día a día
• Tabla comparativa: “caos” vs “sistema”
• Checklist final (copiar/pegar)
• FAQ
• Fuentes y lecturas recomendadas
• Sobre el autor

Saltar al checklist · Saltar a la plantilla

Definición: “sistema de archivos” (en proyectos reales)

Un sistema de archivos es un conjunto de carpetas + convenciones de nombres + reglas de versión + documentación mínima que mantiene el proyecto legible y entregable. No depende de herramientas. Funciona igual si haces web, una app, campañas o un producto digital.

Errores típicos que te cuestan tiempo (y dinero)

• Assets mezclados: logos, exportaciones, screenshots y “finales” en la misma carpeta.
• Nombres basura: “banner nuevo bueno.png”, “logo definitivo definitivo.svg”.
• Sin fuente de verdad: no se sabe cuál es el archivo maestro (Figma/PSD/AI vs exportación).
• Entregables inconsistentes: el cliente recibe formatos distintos cada vez.
• Versiones sin criterio: v1/v2/v3 sin fecha ni contexto.

La estructura mínima recomendada (plantilla)

Esta estructura es suficientemente simple para proyectos pequeños y suficientemente sólida para escalar. La clave: separar “fuentes” de “exportaciones” y “entregables”.

PROYECTO_NOMBRE/
  01_docs/
    brief.md
    decisiones.md
    accesos_y_cuentas.md
    checklist_entrega.md
  02_design/
    fuentes/        (Figma/PSD/AI/Sketch)
    export/         (PNG/SVG/WebP listos)
    brand/          (logo, colores, tipografías, guía)
  03_dev/
    app/            (código)
    env/            (.env.example, configs)
    scripts/        (migraciones, utilidades)
  04_marketing/
    copys/
    creatividades/
    seo/
      keywords.md
      urls_y_slugs.md
  05_deliverables/
    2026-01-22_entrega_01/
      web/
      rrss/
      brand/
  99_archive/
    descartes/
    versiones_antiguas/

Qué va en cada carpeta (sin debate)

• 01_docs: brief, decisiones, accesos, checklist. Si no está aquí, se pierde.
• 02_design/fuentes: editables. Una sola “fuente de verdad”.
• 02_design/export: PNG/SVG/WebP optimizados para uso real.
• 03_dev: código + configs (sin secretos reales dentro del repo).
• 04_marketing: copys, creatividades, keywords, slugs, plan editorial.
• 05_deliverables: entregas con fecha (lo que recibe cliente/equipo).

Links internos (ejemplos): si trabajas la parte de productividad y sistema, conecta este post con: Cómo montar un sistema digital sin volverte loco y Más herramientas, menos productividad.

Naming conventions que sí funcionan

Tu naming tiene que responder 3 preguntas: qué es, para qué canal, qué versión/fecha.

Formato recomendado

[cliente_o_proyecto]_[pieza]_[canal]_[tamano]_[idioma]_[YYYY-MM-DD]_vNN.ext

Ejemplos reales

• vilram_blog_banner_web_1200x630_es_2026-01-22_v01.webp
• vilram_logo_principal_brand_svg_2026-01-22_v03.svg
• vilram_ad_creativo_rrss_1080x1350_es_2026-01-22_v02.png

Versionado simple (sin volverte loco)

Versionar no es poner “v17” porque sí. Es registrar cambios relevantes con mínima fricción.

Reglas rápidas

• v01–v09: iteraciones internas rápidas.
• v10+: solo cuando hay cambios grandes (rebrand, nuevo layout, etc.).
• Entrega: siempre se guarda en 05_deliverables/AAAA-MM-DD_entrega_XX.
• Descartes: van a 99_archive/ (no se borran al azar).

Flujo de trabajo: cómo usarlo día a día

1. Arrancas: creas proyecto con la plantilla y completas 01_docs/brief.md.
2. Diseño: todo editable en 02_design/fuentes; exportaciones optimizadas a 02_design/export.
3. Desarrollo: código en 03_dev/app y configuraciones en 03_dev/env (usa .env.example).
4. Marketing/SEO: keywords, slugs y copys centralizados en 04_marketing.
5. Entrega: todo lo entregable empaquetado por fecha en 05_deliverables.

Ejemplo práctico (caso típico)

Necesitas un banner OG para un post, una versión para RRSS y el archivo editable:

• Editable (fuente): 02_design/fuentes/
• OG optimizado: 02_design/export/ (idealmente WebP y peso controlado)
• Entrega al cliente/equipo: 05_deliverables/2026-01-22_entrega_01/

Tabla comparativa: “caos” vs “sistema”

Pros y contras

Pros

• Menos fricción: encuentras y entregas más rápido.
• Menos errores: menos “subí el archivo equivocado”.
• Escala fácil: cuando el proyecto crece, no colapsa.

Contras

• Disciplina mínima: hay que respetar naming y rutas.
• Primer setup: 10–15 minutos iniciales (se recuperan en la primera semana).

Checklist final (copiar/pegar)

• [ ] Proyecto creado con carpetas base (docs/design/dev/marketing/deliverables)
• [ ] 01_docs/brief.md completo (objetivo, alcance, entregables, responsables)
• [ ] “Fuente de verdad” definida (editables en 02_design/fuentes)
• [ ] Exportaciones optimizadas y consistentes (02_design/export)
• [ ] Naming aplicado (pieza + canal + tamaño + fecha + versión)
• [ ] Entrega empaquetada por fecha (05_deliverables/AAAA-MM-DD_entrega_XX)
• [ ] Archivos antiguos a 99_archive (sin ensuciar carpetas activas)
• [ ] (Cuando uses imágenes) compresión + dimensiones correctas + loading="lazy" donde aplique

FAQ

¿Esto sirve si solo soy autónomo y hago proyectos pequeños?

Sí. De hecho, es donde más se nota: menos tiempo perdido, menos estrés y entregas más limpias.

¿Necesito herramientas específicas (Notion, Drive, etc.)?

No. El sistema funciona en local, en Drive, en Dropbox o en un repo Git. La herramienta no te salva si tu estructura es un vertedero.

¿Qué hago con archivos “temporales” o experimentos?

O van a 99_archive/descartes o a una carpeta tmp dentro del área correspondiente, pero con limpieza semanal.

¿Cómo lo combino con Git?

Guarda código y docs en Git. Para assets pesados, usa exportaciones controladas y evita meter archivos gigantes si no aportan. Mantén .env fuera y usa .env.example.

¿Qué es lo mínimo que NO debo saltarme?

01_docs, separar fuentes vs export y deliverables por fecha. Con eso ya eliminas el 80% del caos.

Fuentes y lecturas recomendadas

• Documentación oficial de Git
• MDN Web Docs (buenas prácticas web)
• web.dev (rendimiento y optimización)

Autor