Maquetación Web y Convenciones

Flujo de Trabajo: Diseño → Maqueta → Desarrollo

Todo proyecto web que valga la pena sigue un flujo de trabajo definido, aunque la rigurosidad varía según el tamaño del equipo y la complejidad del proyecto. El flujo clásico tiene tres fases principales: diseño, maqueta y desarrollo. En equipos grandes, cada fase la hace un rol distinto (diseñador, maquetador, desarrollador). En equipos chicos o proyectos personales, vos hacés las tres, pero el flujo mental es el mismo. Saltarse pasos (por ejemplo, ir directo de un diseño borroso al código) casi siempre genera rework y frustración.

Fase 1: Diseño

Es donde se define qué se va a construir y cómo se va a ver. Puede empezar con wireframes (esquemas de baja fidelidad en blanco y negro que definen la estructura y jerarquía del contenido sin distracción visual) y evolucionar hacia mockups de alta fidelidad (con colores, tipografía, imágenes y espaciado real). Las herramientas más usadas son Figma, Sketch o Adobe XD, pero un papel y lápiz también valen para la fase exploratoria. Lo importante es definir: la jerarquía visual (qué es título, qué es subtítulo, qué es contenido principal), el sistema de grid (cuántas columnas, cuánto gap), la paleta de colores, las tipografías y los componentes que se van a repetir (botones, tarjetas, inputs).

Fase 2: Maqueta (Wireframe técnico)

La maqueta es el paso intermedio entre el diseño visual y el código. Consiste en analizar el diseño y planificar la estructura HTML y el sistema de layout CSS que vas a usar. No es escribir código aún, sino pensarlo: "este hero va a ser un Grid de 2 columnas", "la navbar usa Flexbox con justify-content: space-between", "las cards van en un Grid de 3 columnas con auto-fill para que sea responsive". En esta fase también definís la nomenclatura de clases (BEM, utility-first, etc.) y cómo vas a organizar los archivos CSS. Es como hacer un plano antes de construir una casa: no necesitas dibujar cada ladrillo, pero sí saber dónde van las paredes, las ventanas y las puertas.

Fase 3: Desarrollo (código)

Aquí es donde escribís el HTML semántico, los estilos CSS y el JavaScript necesario. La recomendación es ir de afuera hacia adentro y de arriba hacia abajo: primero la estructura general (header, main, footer), luego las secciones principales, y finalmente los detalles dentro de cada sección. Esto te permite verificar rápidamente que el layout general funciona antes de invertir tiempo en detalles. También es útil desarrollar mobile-first: empezar con los estilos base para pantallas pequeñas y luego agregar media queries para pantallas más grandes. Hacerlo al revés (desktop-first) suele generar másOverrides y códico más difícil de mantener.

1. Analizar el diseño → identificar componentes repetidos
2. Definir design tokens (variables CSS)
3. Armar estructura HTML semántica
4. Aplicar layout CSS (Grid/Flexbox) de afuera hacia adentro
5. Estilizar componentes (tipografía, colores, espaciado)
6. Agregar responsive (media queries mobile-first)
7. Agregar interactividad (JS)
8. Testear en múltiples viewports y navegadores
9. Revisar accesibilidad (contrast, focus, semantics)
10. Optimizar (performance, SEO, bundle size)
                    

Convención BEM: Block Element Modifier

BEM (Block Element Modifier) es una convención de nomenclatura para clases CSS creada por Yandex (el "Google ruso"). Su objetivo es hacer que los nombres de las clases sean autoexplicativos, predecibles y únicos, evitando la especificidad caótica que genera anidar selectores sin control. La premisa es simple: cada clase tiene un propósito claro y no depende de su posición en el DOM. BEM divide las clases en tres categorías:

/* BLOQUE: componente independiente y reutilizable */
.card { }                    /* El bloque: una tarjeta */
.button { }                  /* El bloque: un botón */
.navbar { }                  /* El bloque: la barra de navegación */

/* ELEMENTO: parte interna del bloque, separada con __ (doble guion bajo) */
.card__title { }             /* El título dentro de una card */
.card__body { }              /* El cuerpo dentro de una card */
.card__image { }             /* La imagen dentro de una card */
.navbar__link { }            /* Un link dentro de la navbar */
.navbar__logo { }            /* El logo dentro de la navbar */

/* MODIFIER: variante o estado del bloque/elemento, separada con -- (doble guion medio) */
.card--featured { }          /* Una card en estado "destacado" */
.card--dark { }              /* Una card con variante oscura */
.button--primary { }          /* Un botón de variante primaria */
.button--large { }           /* Un botón de variante grande */
.card__title--uppercase { }  /* El título en variante mayúsculas */
                    

La clave de BEM es que nunca anidas selectores. Cada regla CSS vive al nivel raíz (o a lo sumo dentro de un solo nivel de anidamiento para temas o scopes), y la relación entre block, element y modifier se expresa a través del nombre de la clase, no de la estructura del DOM. Esto significa que .card__title funciona correctamente sin importar si está dentro de un .card o de un .article, porque el nombre de la clase ya describe su contexto. Esto elimina los conflictos de nombres y hace que el CSS sea plano, predecible y fácil de mantener.

BEM en práctica

<!-- Bloque: .user-card -->
<article class="user-card user-card--featured">
    <img class="user-card__avatar" src="foto.jpg" alt="Avatar">
    <div class="user-card__info">
        <h3 class="user-card__name">María González</h3>
        <p class="user-card__role user-card__role--admin">Admin</p>
        <p class="user-card__bio">Desarrolladora frontend en Acme Corp</p>
    </div>
    <div class="user-card__actions">
        <button class="button button--primary">Seguir</button>
        <button class="button button--outline">Mensaje</button>
    </div>
</article>

/* Block */
.user-card {
    display: flex;
    align-items: center;
    gap: var(--space-4);
    padding: var(--space-4);
    background: var(--bg-secondary);
    border-radius: var(--radius-md);
    border: 1px solid var(--border-color);
}

/* Modifier */
.user-card--featured {
    border-color: var(--accent-blue);
    box-shadow: 0 0 0 1px var(--accent-blue);
}

/* Elements */
.user-card__avatar {
    width: 64px;
    height: 64px;
    border-radius: 50%;
    object-fit: cover;
}

.user-card__name {
    font-family: var(--font-heading);
    font-size: var(--font-size-lg);
    color: var(--text-primary);
    margin: 0;
}

.user-card__role {
    font-size: var(--font-size-sm);
    color: var(--text-muted);
    margin: var(--space-1) 0;
}

/* Element + Modifier */
.user-card__role--admin {
    color: var(--accent-purple);
    font-weight: var(--font-weight-semibold);
}

.user-card__bio {
    font-size: var(--font-size-sm);
    color: var(--text-secondary);
    line-height: var(--line-height-relaxed);
    margin: var(--space-2) 0 0;
}

Cuándo (y cuándo no) usar BEM

BEM brilla en proyectos de tamaño mediano a grande, donde múltiples personas trabajan en el mismo CSS o donde el proyecto va a crecer significativamente. En proyectos pequeños o prototipos rápidos, la verbosity de BEM puede sentirse excesiva. También, si usás un framework utility-first como Tailwind CSS, BEM tiene menos sentido porque las clases utilitarias ya evitan la necesidad de nombres semánticos personalizados. Lo importante es ser consistente: elegí una convención y aplicala en todo el proyecto. Mezclar BEM con nombres inventados al azar es peor que no usar ninguna convención.

Diseño Mobile-First

Mobile-first es una filosofía de desarrollo que consiste en escribir primero los estilos para la versión móvil (pantallas pequeñas) y luego usar min-width media queries para ir agregando complejidad a medida que el viewport crece. Es lo opuesto a desktop-first, donde empezás con la versión de escritorio y usás max-width para "achicar" cosas en pantallas menores. Mobile-first no es solo una técnica CSS: es un cambio de mentalidad. Obliga a priorizar el contenido esencial, a pensar en la UX en condiciones restrictivas (pantalla chica, touch, conexión lenta) y a agregar funcionalidad progresivamente en lugar de quitarla.

La razón principal para usar mobile-first es que los estilos base (sin media queries) se aplican a todos los dispositivos. Si empezás con mobile, esos estilos base son los mínimos necesarios para que la página funcione. Luego, las media queries con min-width solo agregan o modifican lo que hace falta para pantallas más grandes. Si hacés desktop-first, los estilos base son para escritorio, y necesitás más media queries para "corregir" todo en móviles, lo que genera más código y más puntos de falla. Estadísticamente, más de la mitad del tráfico web mundial viene desde dispositivos móviles, así que tiene sentido empezar por allí.

/* === BASE: Móvil (sin media query) === */
.container {
    width: 100%;
    padding: 0 var(--space-4);
}

.grid {
    display: grid;
    gap: var(--space-4);
    grid-template-columns: 1fr; /* 1 columna en móvil */
}

.hero {
    padding: var(--space-6) 0;
    text-align: center;
}

.hero__title {
    font-size: var(--font-size-xl); /* Tamaño móvil */
}

.nav {
    flex-direction: column; /* Stack vertical en móvil */
    gap: var(--space-2);
}

/* === TABLET: min-width 768px === */
@media (min-width: 768px) {
    .container {
        max-width: 720px;
        margin: 0 auto;
    }

    .grid {
        grid-template-columns: repeat(2, 1fr); /* 2 columnas */
    }

    .hero__title {
        font-size: var(--font-size-2xl); /* Más grande en tablet */
    }

    .nav {
        flex-direction: row; /* Horizontal en tablet+ */
    }
}

/* === DESKTOP: min-width 1024px === */
@media (min-width: 1024px) {
    .container {
        max-width: 1200px;
    }

    .grid {
        grid-template-columns: repeat(3, 1fr); /* 3 columnas */
    }

    .hero__title {
        font-size: var(--font-size-3xl); /* Más grande en desktop */
    }
}

/* === WIDE: min-width 1440px === */
@media (min-width: 1440px) {
    .container {
        max-width: 1400px;
    }
}

Progressive Enhancement vs. Graceful Degradation

Mobile-first está alineado con el concepto de Progressive Enhancement (mejora progresiva): empezás con una experiencia básica que funciona para todos (incluso navegadores antiguos o conexiones lentas) y vas agregando funcionalidades y estilos avanzados para navegadores y dispositivos más capaces. Es lo opuesto a Graceful Degradation (degradación elegante), donde empezás con la versión completa (desktop) y vas quitando cosas para que funcione en dispositivos menores. Progressive Enhancement es generalmente considerado superior porque garantiza una experiencia funcional para todos, mientras que Graceful Degradation a menudo deja la experiencia móvil como un "afterthought".

Estrategia de Breakpoints

Los breakpoints son los puntos de corte donde el layout de tu página cambia para adaptarse a un tamaño de pantalla diferente. No son un número mágico: deberían definirse en función del contenido, no de los dispositivos específicos. Un error común es usar breakpoints fijos como "320px para iPhone" o "768px para iPad", lo que genera un layout frágil que se rompe en dispositivos con resoluciones intermedias. La estrategia correcta es: el contenido define los breakpoints. Agregá un breakpoint cuando el diseño actual deja de verse bien, no cuando cambia el nombre del dispositivo.

Dicho esto, existen breakpoints comunes que funcionan como punto de partida en la mayoría de los proyectos. Estos valores no son universalmente correctos, pero son un buen default hasta que tu contenido te diga lo contrario. Lo importante es que los definas como CSS custom properties para mantenerlos centralizados y fáciles de modificar.

/* === Breakpoints como Custom Properties === */
:root {
    /* Breakpoints (valores de referencia, no reglas estrictas) */
    --bp-sm: 640px;    /* Small: teléfonos grandes / landscape */
    --bp-md: 768px;    /* Medium: tablets portrait */
    --bp-lg: 1024px;   /* Large: tablets landscape / laptops */
    --bp-xl: 1280px;   /* XL: desktops estándar */
    --bp-2xl: 1536px;  /* 2XL: desktops grandes */
}

/* Nota: Las custom properties NO funcionan dentro de @media.
   Usá los valores directamente o define los breakpoints
   con un preprocesador/mixin. */

/* Breakpoints directos (más práctico) */
@media (min-width: 640px) { /* sm */ }
@media (min-width: 768px) { /* md */ }
@media (min-width: 1024px) { /* lg */ }
@media (min-width: 1280px) { /* xl */ }
@media (min-width: 1536px) { /* 2xl */ }

Content-based breakpoints

La mejor estrategia es no definir breakpoints por adelantado, sino ir ajustándolos mientras maquetás. Redimensioná el navegador y cuando un elemento se vea mal (texto truncado, imágenes desproporcionadas, demasiado espacio vacío), ahí agregá un breakpoint. Esto genera breakpoints únicos para cada proyecto, más orgánicos y menos frágiles. Por ejemplo, en vez de un breakpoint genérico de 768px, podrías terminar con uno en 850px porque es exactamente donde tu sidebar colapsa bien. La regla: los breakpoints nacen del contenido, no del dispositivo.

Container queries: el futuro

Los Container Queries (@container) son una funcionalidad relativamente nueva que permite que un componente responda al tamaño de su contenedor padre, no al viewport. Esto resuelve un problema fundamental de las media queries: un componente como una card debería verse diferente si está en un sidebar estrecho vs. en el contenido principal, sin importar el tamaño de la pantalla. Con @container, el componente se adapta a su contexto, lo que lo hace mucho más reutilizable. El soporte de navegadores es excelente a partir de 2023-2024 (Chrome, Firefox, Safari todos lo soportan), así que ya es viable usarlo en producción.

/* Definir el contenedor */
.card-wrapper {
    container-type: inline-size;
    container-name: card-container;
}

/* El componente responde al tamaño de SU contenedor */
@container card-container (min-width: 400px) {
    .card {
        display: grid;
        grid-template-columns: 200px 1fr;
        gap: var(--space-4);
    }

    .card__image {
        height: 100%;
        object-fit: cover;
    }
}

/* Si el contenedor es chico, layout vertical */
@container card-container (max-width: 399px) {
    .card {
        display: flex;
        flex-direction: column;
    }

    .card__image {
        width: 100%;
        aspect-ratio: 16 / 9;
    }
}

Componentes Atómicos: Atoms → Molecules → Organisms

Atomic Design, creado por Brad Frost, es una metodología para construir interfaces descomponiéndolas en sus partes más pequeñas y recomponiéndolas jerárquicamente. La analogía es con la química: los átomos se combinan para formar moléculas, las moléculas se combinan para formar organismos, y los organismos se combinan para formar templates y páginas. Esta metodología no depende de ninguna tecnología específica (funciona igual con HTML/CSS vanilla, con React, con Vue, con lo que sea) y su valor principal es forzarte a pensar en reutilización desde el inicio.

Los 5 niveles de Atomic Design

Ejemplo práctico: una card de producto

Una card de producto en un e-commerce es un ejemplo perfecto de cómo funcionan los niveles de Atomic Design. El botón "Comprar" es un atom. La estrella de rating es otro atom. El precio con formato es un atom. Cuando combinás la imagen del producto + el título + el precio, tenés una molecule (el cuerpo de la card). Cuando le agregás el botón de compra + las estrellas de rating + el badge de descuento, tenés un organism (la card completa). Varias cards juntas en un grid forman parte de un template de categoría de productos, y la página final con el header, el grid de cards y el footer es una page.

<!-- ATOMS: componentes indivisibles -->
<!-- Usados dentro de la card pero también en otras partes -->

<!-- Molecule: product-card__body (img + title + price) -->
<div class="product-card__body">
    <img class="product-card__image" src="product.jpg" alt="Producto">
    <h3 class="product-card__title">Auriculares Bluetooth</h3>
    <span class="product-card__price">$4.999</span>
</div>

<!-- Molecule: product-card__rating (stars + count) -->
<div class="product-card__rating">
    <div class="stars">★★★★☆</div>
    <span class="rating__count">(127 reseñas)</span>
</div>

<!-- ORGANISM: product-card completa -->
<article class="product-card product-card--sale">
    <span class="product-card__badge">-30%</span>
    <div class="product-card__body">
        <img class="product-card__image" src="product.jpg" alt="Producto">
        <h3 class="product-card__title">Auriculares Bluetooth</h3>
        <span class="product-card__price">$4.999</span>
    </div>
    <div class="product-card__rating">
        <div class="stars">★★★★☆</div>
        <span class="rating__count">(127 reseñas)</span>
    </div>
    <button class="button button--primary product-card__cta">
        Agregar al carrito
    </button>
</article>

Organización de archivos con Atomic Design

Una de las ventajas prácticas de Atomic Design es que sugiere una estructura de carpetas lógica que escala bien. En proyectos grandes, cada nivel puede tener su propia carpeta con archivos CSS (o componentes, si usás un framework JS). Esto hace fácil encontrar dónde están definidos los estilos de un componente y evita archivos gigantes de miles de líneas que nadie se anima a tocar.

css/
ˆˆ— atoms/
ˆ—— button.css
ˆ—— input.css
ˆ—— badge.css
ˆ—— icon.css
ˆ— molecules/
ˆ—— search-bar.css
ˆ—— card-body.css
ˆ—— price-tag.css
ˆ— organisms/
ˆ—— navbar.css
ˆ—— card.css
ˆ—— hero.css
ˆ—— footer.css
ˆ— templates/
ˆ—— blog-layout.css
ˆ—— dashboard-layout.css
ˆ— globals.css  (reset, variables, tipografía base)
                    

Herramientas Esenciales

Conocer las herramientas correctas puede marcar una diferencia enorme en tu productividad y en la calidad de tu maquetación. No se trata de usar todas las herramientas disponibles, sino de tener un set básico que cubra las necesidades principales: inspeccionar diseños, medir distancias, probar responsividad, depurar CSS y automatizar tareas repetitivas. Acá van las herramientas que todo maquetador frontend debería conocer y dominar, desde las más básicas hasta las más avanzadas.

De Figma a Código

Figma es el estándar de la industria para diseño UI y tu fuente principal de "verdad visual" cuando maquetás. La clave es aprender a usarlo eficientemente como desarrollador, no como diseñador. Las funciones más útiles para devs son: inspeccionar propiedades (click derecho en un elemento → "Copy as CSS" para obtener spacing, colors, fonts), medir distancias (mantener Alt/Opt y hover sobre otro elemento para ver la distancia en píxeles), exportar assets (click en un asset → Export → elegir formato y escala), y navegar el prototipo (para entender el flujo de interacción). Figma también tiene plugins que generan código automáticamente (como Anima, Locofy), pero la calidad del código generado suele ser mediocre—es mejor usarlos como referencia y escribir el código tú mismo.

Chrome DevTools

Las DevTools del navegador (accesibles con F12 o Ctrl+Shift+I) son tu mejor amigo durante la maquetación. La pestaña Elements te permite inspeccionar y modificar el HTML y CSS en tiempo real, ver qué reglas se aplican a cada elemento, entender la cascada y la especificidad, y probar cambios rápidamente sin tocar los archivos. La pestaña Device Toolbar (icono de celu en la esquina superior izquierda) simula diferentes viewports para testear responsividad. La pestaña Layout muestra visualmente los márgenes, paddings, borders y Grid/Flexbox overlays del elemento seleccionado, lo que es invaluable para debuggear problemas de layout.

Ctrl + Shift + C        → Seleccionar elemento haciendo click en la página
Ctrl + Shift + M        → Toggle Device Toolbar (modo responsive)
H                       → Ocultar/mostrar el elemento seleccionado
F                       → Toggle Flexbox/Grid overlay del contenedor
Ctrl + Shift + I        → Abrir DevTools
Ctrl + [                → Colapsar el nodo seleccionado en el panel Elements
Ctrl + Shift + C        → Modo selector (click para inspeccionar)
Tab                     → Navegar al siguiente atributo/propiedad editable
Esc                     → Mostrar/ocultar Console drawer
Ctrl + Shift + D        → Dock DevTools en ventana separada

Grid Overlays y Debugging

Ver el grid invisible es crucial para debuggear layouts CSS. Los navegadores modernos tienen Grid overlays integrados en las DevTools: en Chrome, seleccioná un contenedor Grid, y verás opciones como "Grid" y "Gap" en el panel Layout. Firefox lleva esto aún más lejos con su Grid Inspector, que muestra números de líneas, áreas de grid nombradas y overlay de gaps coloreados. Para Flexbox, el Flexbox inspector (disponible en Chrome y Firefox) muestra los ejes principales/cruzados, el justify-content y el align-items visualmente. Si necesitás algo más visual y permanente, extensiones como CSS Peeper o WhatFont te permiten inspeccionar los estilos de cualquier website sin abrir DevTools.

Herramientas de medicción y alineación

Para verificar que tu maquetación coincida con el diseño, necesitas poder medir distancias con precisión. Dentro de Figma, las distancias se muestran automáticamente cuando mantés Alt/Opt y hover sobre elementos. En el navegador, las DevTools muestran las dimensiones y espaciados del elemento seleccionado. Para mediciones más flexibles, extensiones como PerfectPixel te permiten superponer una imagen del diseño exportada desde Figma sobre tu página y comparar píxel por píxel. Page Ruler es otra extensión que funciona como una regla virtual sobre la página para medir distancias entre cualquier par de puntos.

Preview en múltiples dispositivos

Para testear responsividad, no alcanza con el Device Toolbar de Chrome. Las simulaciones de navegador pueden no reflejar exactamente cómo se ve tu sitio en un dispositivo real (por diferencias en pixel ratio, rendering engine, comportamientos de scroll nativos). Las opciones van desde Responsively App (una app desktop que muestra tu sitio en múltiples viewports simultáneamente y sincroniza scroll/click entre ellos) hasta Chrome DevTools Device Pairing (conectás tu teléfono real via USB y usás DevTools de Chrome desktop para inspeccionar lo que se ve en tu celu). Para cobertura total de navegadores, servicios como BrowserStack o LambdaTest te dan acceso a máquinas virtuales con cualquier combinación de OS + navegador, útil especialmente para verificar bugs en Safari/IE/Edge antiguos.

Buenas Prácticas de Maquetación

Después de cubrir las metodologías y herramientas, vale la pena consolidar las buenas prácticas que separan a una maquetación profesional de un código chapucero. Estas recomendaciones se acumulan con la experiencia y son el resultado de años de lecciones aprendidas por la comunidad de desarrollo frontend. No todas aplican a todo proyecto, pero como reglas generales te van a ahorrar dolores de cabeza significativos.

Semántica sobre divitis

Usá HTML semántico (<header>, <nav>, <main>, <article>, <section>, <aside>, <footer>) en lugar de envolver todo en <div>. La semántica no solo mejora la accesibilidad (screen readers usan las etiquetas para navegar) y el SEO (los motores de búsqueda entienden mejor la estructura), sino que también hace tu código más legible y autoexplicativo. La regla: si un <div> puede ser reemplazado por una etiqueta semántica con el mismo efecto visual, usá la etiqueta semántica. Solo usá <div> y <span> como último recurso, cuando no existe una etiqueta más apropiada.

Evita el posicionamiento absoluto para layout

position: absolute y position: fixed deberían usarse para casos específicos (tooltips, modales, badges, decorative elements), no para construir el layout general de la página. Un layout basado en posiciones absolutas es frágil, no fluye con el contenido y es prácticamente imposible de hacer responsive. Flexbox y Grid cubren el 99% de las necesidades de layout y manejan el flujo de contenido de forma natural. Si te encontrás usando mucho position: absolute para organizar elementos, probablemente necesitás repensar tu enfoque de layout.

Nunca uses !important como primera opción

!important rompe la cascada natural de CSS y hace que el código sea impredecible. Si necesitás !important, es una señal de que la especificidad de tus selectores está mal gestionada. Las únicas excepciones legítimas son: utility classes que deben ganar sobre todo (en frameworks utility-first), estilos de terceros que necesitas sobreescribir, y resets/overrides globales muy específicos. En tu propio CSS, la solución es usar selectores más específicos o reestructurar las reglas para evitar el conflicto.

Mantén tus media queries cerca del componente

Hay dos escuelas: poner todas las media queries al final del archivo (fácil de encontrar) o poner cada media query justo debajo del componente que modifica (fácil de mantener). La segunda opción es generalmente mejor para proyectos grandes porque cuando editás un componente, todo lo relacionado está junto. Si usás CSS nativo sin preprocesador, esto significa que en el mismo archivo podés tener el estilo base del componente seguido de sus media queries. Con Sass/LESS, podés usar el mixin @include respond-to(md) { ... } para mantener las media queries inline sin perder legibilidad.

Testea en viewports reales

Las DevTools son geniales para un rápido testeo, pero no reemplazan el testing en dispositivos reales. Cosas que pueden verse bien en la simulación pero fallar en un dispositivo real incluyen: comportamientos de scroll (overscroll, bounce), teclado virtual que achica el viewport, hover states que no existen en touch, rendimiento de animaciones, y renderizado de fuentes. Si podés, tené al menos un par de dispositivos físicos (un iPhone y un Android, preferentemente) para verificar antes de hacer deploy.