Para elegir una agencia de diseño web, primero definí los requisitos obligatorios y compará todas las propuestas con los mismos 12 criterios. En cada uno marcá incluido, excluido, opcional o no especificado, y pedí evidencia, responsable y criterio de aceptación. Normalizá moneda, impuestos, costos de terceros y costo total del primer año. No sumes un puntaje único: una exclusión crítica no se compensa con varias ventajas menores.
Antes de comparar agencias, definí qué es obligatorio
Dos propuestas pueden tener totales distintos porque resuelven problemas diferentes. Antes de pedirlas, documentá qué debe lograr el sitio, quiénes lo van a usar, qué acciones deberían poder completar y qué restricciones existen. Incluí contenidos, idiomas, integraciones, migraciones, responsables internos y necesidades de operación posterior.
Clasificá cada necesidad en uno de estos niveles:
- Obligatorio: si no se cumple, la propuesta no resulta viable para el proyecto.
- Preferencia: agrega valor, pero puede negociarse o resolverse de otra manera.
- No aplica: no es necesario para este alcance.
Luego usá la matriz en tres pasos:
- Clasificá cada necesidad como obligatoria, preferencia o no aplica antes de solicitar o evaluar propuestas.
- Marcá el estado de cada criterio por proveedor como incluido, excluido, opcional o no especificado, y registrá la evidencia documental.
- Resolvé primero los incumplimientos obligatorios. Después compará preferencias, condiciones y costo total normalizado. No compenses una exclusión crítica con un promedio alto.
Matriz de 12 criterios para comparar propuestas de diseño web
*Doce criterios, tres propuestas, cuatro estados. No es un puntaje ni un ranking.*
La tabla resume qué comparar, qué evidencia pedir y qué respuestas deberían generar una aclaración. No es una tabla de puntajes: usala para detectar diferencias de alcance, faltantes y decisiones pendientes.
1. Diagnóstico y comprensión del negocio
- Qué comparar: Objetivos, públicos, recorridos, restricciones y supuestos que sostienen la solución.
- Evidencia a pedir: Brief, agenda o entregable de descubrimiento; síntesis de objetivos y supuestos por validar.
- Pregunta de control: ¿Qué necesitan conocer antes de recomendar pantallas o tecnología y qué entregable deja esa etapa?
- Red flag: Recomiendan una solución cerrada antes de preguntar por objetivos, operación o restricciones.
2. Alcance, entregables y exclusiones
- Qué comparar: Páginas o tipos de contenido, funcionalidades, idiomas, integraciones, migración, carga, revisiones y exclusiones.
- Evidencia a pedir: Alcance desglosado, inventario funcional y lista de incluido / excluido / opcional con supuestos.
- Pregunta de control: ¿Qué entregables concretos recibimos y qué situación activa un adicional?
- Red flag: Verbos amplios sin cantidades, límites, responsables ni tratamiento de cambios.
3. Proceso y gobierno del proyecto
- Qué comparar: Fases, hitos, responsables, validaciones, dependencias, calendario y gestión de cambios.
- Evidencia a pedir: Plan de trabajo, hitos de aprobación, matriz de responsables y mecanismo de change request.
- Pregunta de control: ¿Quién decide y aprueba cada etapa, y qué ocurre si cambia el alcance o se demora una dependencia?
- Red flag: Hay fecha final, pero no hitos, responsables, dependencias ni proceso para cambios.
4. UX, contenido y accesibilidad
- Qué comparar: Arquitectura, wireframes, responsive, insumos de investigación, creación y carga de contenidos, y nivel WCAG cuando corresponda.
- Evidencia a pedir: Mapa del sitio, wireframes o prototipo, alcance responsive, matriz de contenidos y criterios de accesibilidad.
- Pregunta de control: ¿Qué se valida antes del diseño visual y quién redacta, adapta, aprueba y carga los contenidos?
- Red flag: “UX” o “accesible” aparece como etiqueta sin artefactos, alcance ni aceptación.
5. Tecnología y operación futura
- Qué comparar: Adecuación del CMS o desarrollo a medida a edición, permisos, integraciones, licencias, mantenimiento y portabilidad.
- Evidencia a pedir: Demo del flujo editorial, arquitectura o stack, inventario de licencias e integraciones, y restricciones.
- Pregunta de control: ¿Qué podrá editar el equipo sin depender del proveedor y qué costos o límites tendrá la solución?
- Red flag: La tecnología se presenta como superior por marca, sin relacionarla con la operación.
6. SEO técnico y migración
- Qué comparar: Indexabilidad, rastreo, metadatos, URLs, canonización, sitemap, redirecciones y Search Console; lanzamiento frente a servicio continuo.
- Evidencia a pedir: Checklist de lanzamiento y, si cambian URLs, inventario, mapeo, plan de redirecciones, pruebas y monitoreo.
- Pregunta de control: Cuando dicen “SEO incluido”, ¿qué entregables de lanzamiento abarca y qué queda para un servicio continuo?
- Red flag: Promesas de posiciones o tráfico; “SEO incluido” sin entregables ni responsabilidad sobre migración.
7. Performance y seguridad
- Qué comparar: Objetivos medibles, método y momento de medición, laboratorio frente a campo; actualizaciones y controles acordes al riesgo.
- Evidencia a pedir: Presupuesto de performance, herramientas o datos previstos, responsabilidades de infraestructura y requisitos de seguridad.
- Pregunta de control: ¿Qué métricas medirán, con qué datos, en qué condiciones y quién corrige después del lanzamiento?
- Red flag: “Carga en X segundos”, “100 % seguro” u “optimizado” sin métrica, contexto ni verificación.
8. Medición y conversiones
- Qué comparar: Acciones clave, eventos, consentimiento cuando corresponda, implementación, QA, accesos y responsables.
- Evidencia a pedir: Plan de medición, lista de eventos y key events, procedimiento de validación y titularidad de cuentas.
- Pregunta de control: ¿Qué acciones de negocio quedarán medidas y cómo comprobaremos que los eventos funcionan?
- Red flag: La medición se reduce a “instalar Analytics” sin eventos, validación ni accesos del cliente.
9. Propiedad, accesos y portabilidad
- Qué comparar: Titularidad y control de dominio, hosting, repositorio, CMS, diseños, contenidos, datos, analítica y credenciales.
- Evidencia a pedir: Inventario de activos y cuentas con titular, administrador, momento de entrega y formato exportable.
- Pregunta de control: ¿Qué quedará a nombre del cliente y qué recibiremos si termina la relación?
- Red flag: Cuentas críticas sólo a nombre del proveedor o imposibilidad no explicada de exportar activos o datos.
10. QA y aceptación
- Qué comparar: Navegadores, dispositivos y tecnologías asistivas; pruebas funcionales, de formularios, contenido, SEO y accesibilidad.
- Evidencia a pedir: Plan o casos de prueba, matriz de cobertura, registro de incidencias y criterios de aceptación.
- Pregunta de control: ¿Qué se probará, en qué entornos y qué condiciones deben cumplirse para aprobar?
- Red flag: “Probamos todo” sin cobertura acordada, evidencia ni criterio de cierre.
11. Publicación, soporte y mantenimiento
- Qué comparar: Responsables del go-live, backups, monitoreo, garantía, canal, horario, respuesta, actualizaciones y evolutivos.
- Evidencia a pedir: Plan de publicación y reversión, política de backups, alcance de garantía, SLA si aplica y mantenimiento.
- Pregunta de control: ¿Qué ocurre desde el día posterior a publicar y qué diferencia garantía, soporte y mantenimiento?
- Red flag: “Soporte incluido” sin plazo, canal, horario, tiempos, límites ni costos posteriores.
12. Evidencia, equipo y comparabilidad comercial
- Qué comparar: Trabajos activos y rol real, equipo asignado, disponibilidad, monto comparable, pagos, moneda, impuestos, vigencia y terceros.
- Evidencia a pedir: URLs activas con alcance atribuible, roles del equipo, propuesta económica desglosada y condiciones.
- Pregunta de control: ¿Qué parte hicieron en los trabajos mostrados, quién trabajará en el nuestro y cuál es el costo normalizado?
- Red flag: Resultados no demostrables, portfolio sin rol atribuible, equipo indefinido o total que mezcla alcances diferentes.
Para una planilla copiable, agregá estas columnas a cada criterio: nivel para este proyecto; estado de la propuesta; entregable y evidencia; responsable del cliente, agencia o tercero; criterio de aceptación; dependencias o supuestos; costo inicial; costo recurrente o de tercero; duda por resolver.
Estrategia, alcance y gobierno del proyecto
1. Diagnóstico y comprensión del negocio
Un diagnóstico útil no se demuestra con la frase “entendemos tu negocio”. La propuesta debería indicar qué información necesita el equipo antes de definir la solución: objetivos, públicos, recorridos prioritarios, restricciones técnicas u operativas, antecedentes y supuestos por validar.
Compará tanto la actividad como su resultado. Una reunión inicial puede ser parte del proceso, pero la evidencia es el artefacto que deja: por ejemplo, un brief acordado, una síntesis de objetivos, un mapa de necesidades o una definición del problema. También debería quedar claro quién aporta información y quién la valida.
Respuesta vaga: “Primero analizamos tu negocio”.
Respuesta verificable: detalla las instancias de descubrimiento, participantes, insumos necesarios, entregable resultante y momento de aprobación.
La señal para pausar es una solución ya cerrada —pantallas, plataforma o funcionalidades— antes de conocer cómo trabaja la organización y qué restricciones condicionan el proyecto.
2. Alcance, entregables y exclusiones
El alcance vuelve comparables los precios. Pedí que diferencie páginas o tipos de contenido, funcionalidades, idiomas, integraciones, migración, redacción, carga, capacitación y revisiones. No alcanza con “diseño completo” o “integración con el sistema”: debe poder identificarse qué se entrega y dónde termina el compromiso.
Revisá especialmente las exclusiones, los opcionales y los supuestos. Si algo figura como no especificado, no lo trates como incluido. Preguntá qué evento activa un adicional: una nueva funcionalidad, otra ronda de revisión, un cambio sobre algo aprobado o un insumo que llega en condiciones distintas de las previstas.
3. Proceso y gobierno
Una fecha final no explica cómo se administra un proyecto. Compará fases, hitos, responsables, instancias de aprobación, dependencias y mecanismo de cambios. El calendario debería distinguir el trabajo del proveedor de los insumos y decisiones que corresponden al cliente o a terceros.
Pedí una matriz simple de responsables: quién ejecuta, quién entrega contenidos o accesos, quién revisa y quién tiene autoridad para aprobar. Si participan marketing, dirección, sistemas o un proveedor externo, definir esas intervenciones reduce decisiones contradictorias.
Experiencia, tecnología y descubrimiento orgánico
4. UX, contenido y accesibilidad
“Diseño UX/UI” puede abarcar trabajos muy distintos. Pedí que la propuesta nombre los artefactos: arquitectura de información, mapa del sitio, wireframes, prototipo, diseño visual y reglas de responsive design. También debería indicar qué se valida antes de avanzar y qué ocurre si una etapa aprobada cambia.
El contenido necesita responsables: quién hace el inventario, redacta, adapta, traduce, aprueba y carga. Una interfaz no puede evaluarse de manera aislada si todavía depende de textos o imágenes inexistentes.
La experiencia móvil tampoco debería quedar como revisión secundaria: Google explica que utiliza la versión móvil del contenido para indexación y ranking. En la propuesta, esto se traduce en alcance responsive, contenidos equivalentes y pruebas acordadas, no en una mención decorativa.
Si la accesibilidad es requisito, reemplazá “sitio accesible” por una referencia verificable. WCAG 2.2 define criterios de éxito y niveles A, AA y AAA, pero el nivel aplicable debe acordarse según el proyecto, el contrato y la jurisdicción. Nombrar WCAG no demuestra conformidad por sí solo.
5. Tecnología y operación futura
La pregunta no es qué tecnología gana en abstracto, sino qué operación permite. WordPress, Webflow y Shopify son ejemplos de plataformas con modelos diferentes; un CMS estándar, una plantilla adaptada o un desarrollo a medida deben evaluarse según edición, permisos, integraciones, personalización, licencias, mantenimiento y portabilidad.
Pedí una demostración del flujo cotidiano: crear o editar contenido, administrar usuarios, actualizar información repetitiva y recuperar una versión. Identificá qué cambios podrá hacer el equipo interno, cuáles requerirán al proveedor y cuáles dependen de un tercero.
El inventario técnico debería incluir hosting, certificado TLS, integraciones, plugins, aplicaciones, APIs y licencias, junto con sus titulares, renovaciones y restricciones. “Escalable” o “flexible” sólo se vuelve comparable cuando la propuesta indica qué necesidad futura contempla y qué parte podría requerir un nuevo alcance.
6. SEO técnico y migración
El SEO técnico de lanzamiento debe definirse antes de construir o rediseñar. Google señala que puede ser útil considerar asesoramiento SEO antes de crear un sitio o cambiar su diseño, no únicamente después de publicar.
Pedí entregables concretos: tratamiento de rastreo e indexación, metadatos, URLs, canonización, sitemap, acceso a Google Search Console y checklist de lanzamiento. La documentación oficial permite traducir la etiqueta “SEO incluido” a condiciones sobre cómo los buscadores acceden, indexan y comprenden el sitio. Esto no equivale a contratar investigación de demanda, producción editorial o mejora continua: si esos trabajos existen, deben figurar como un servicio separado.
En un rediseño que cambia URLs, solicitá inventario de direcciones actuales, mapeo hacia las nuevas, redirecciones permanentes, pruebas y monitoreo. Es el proceso que describe la guía de Google para migraciones con cambios de URL. Aclaralo incluso si la migración depende de otro proveedor.
El mapa de rastreo, índice y ranking, sin redefinir el servicio, está en qué es el SEO y cómo funciona en 2026.
Una garantía de primera posición es una red flag: la misma documentación de Google advierte que nadie puede garantizarla. La aceptación del proyecto debe basarse en entregables controlables, no en posiciones o tráfico prometidos.
Calidad técnica, medición y control de activos
7. Performance y seguridad
“Sitio rápido” no define qué se mide, en qué condiciones ni con qué datos. Si la propuesta promete Core Web Vitals, pedí que nombre LCP, INP y CLS, la fuente de datos, el momento de medición y quién corrige desvíos. La referencia de web.dev sobre Web Vitals distingue datos reales de usuarios y pruebas de laboratorio. Herramientas como PageSpeed Insights y Lighthouse pueden participar de la evaluación, pero sus resultados deben interpretarse según el método acordado.
Separá también las responsabilidades: código, contenidos, etiquetas de terceros, hosting e infraestructura pueden intervenir en el resultado. El criterio de aceptación tiene que reflejar qué controla cada parte y cuándo se realiza la prueba.
En seguridad, evitá garantías absolutas. Pedí responsabilidades sobre actualizaciones, accesos, backups, certificado TLS, dependencias y respuesta ante incidentes, de acuerdo con el riesgo del proyecto. Para una aplicación con requisitos relevantes, OWASP ASVS puede utilizarse como base para especificar verificaciones en procurement o contratos. Es una referencia posible, no una obligación para todo sitio ni una garantía de seguridad.
8. Medición y conversiones
“Instalar Analytics” describe una herramienta, no un plan de medición. Empezá por las acciones que importan: enviar un formulario, iniciar un contacto, registrarse, descargar un documento, completar una compra u otra interacción propia del proyecto.
Pedí una lista de eventos, su condición de activación, parámetros, responsable de implementación y procedimiento de prueba. Google Analytics 4 mide interacciones mediante eventos y permite marcar acciones importantes como key events; la propuesta debería indicar cuáles se implementan y cómo se validan.
Acordá además quién será titular de la cuenta, quién tendrá accesos y si se contempla consentimiento cuando corresponda. Diferenciá la implementación y el QA inicial del análisis continuo: que los eventos queden configurados no implica que el proveedor vaya a interpretar los datos de manera recurrente.
9. Propiedad, accesos y portabilidad
“El sitio es tuyo” necesita un inventario operativo. Registrá dominio, hosting, repositorio y código fuente, CMS, archivos de diseño, contenidos, datos, analítica, integraciones, licencias, cuentas, accesos y credenciales.
Para cada activo, identificá titular, administradores, momento de entrega y formato disponible. Tener un usuario no siempre equivale a controlar la cuenta; poder ver contenidos no necesariamente implica poder exportarlos o migrarlos. La propuesta o el contrato deberían explicar qué sucede al terminar la relación y qué asistencia de salida está incluida, excluida u ofrecida como opcional.
10. QA y aceptación
“Probamos todo” no es un plan de calidad. Definí qué se va a verificar: funcionalidades, formularios, responsive, contenidos, integraciones, metadatos, accesibilidad y publicación. La cobertura debe nombrar entornos, navegadores, dispositivos y, cuando aplique, tecnologías asistivas.
No resulta viable probar todas las combinaciones posibles; MDN recomienda acordar con el cliente el rango de navegadores y dispositivos cubierto. Pedí además cómo se registran incidencias, cómo se determina severidad, quién corrige y cuándo se hace el retest.
En accesibilidad, una auditoría automática no basta para declarar conformidad: W3C aclara que ninguna herramienta por sí sola puede determinarla y que hace falta evaluación humana competente. El alcance debe indicar qué combinación de evaluación automática, revisión humana y prueba con tecnologías asistivas se realizará.
Cerrá esta fila con criterios de aceptación: qué condiciones deben cumplirse para aprobar, quién firma la conformidad y qué defectos pasan a garantía.
Continuidad, evidencia y condiciones comerciales
11. Publicación, soporte y mantenimiento
El alcance no termina necesariamente cuando el sitio queda visible. Pedí un plan de go-live con responsables, verificaciones, backups y alternativa de reversión. Aclarar estos puntos permite saber quién actúa si aparece un problema durante la publicación.
Después, separá tres conceptos:
- Garantía: corrección de defectos respecto del alcance aceptado, dentro de las condiciones pactadas.
- Soporte: atención de consultas o incidentes por un canal, horario, alcance y esquema de respuesta definidos.
- Mantenimiento: trabajo preventivo, actualizaciones o mejoras evolutivas que pueden ser recurrentes o contratarse por separado.
Si se ofrece un SLA, revisá qué servicio cubre, prioridades, horarios y compromisos. No todos los proyectos necesitan el mismo esquema. La frase “soporte incluido” sólo es comparable si informa duración, canal, límites, responsabilidades y costo posterior.
12. Evidencia, equipo y comparabilidad comercial
El portfolio sirve para abrir preguntas, no para inferir resultados. Solicitá URLs activas y preguntá qué parte realizó el proveedor: diagnóstico, diseño, desarrollo, contenidos, mantenimiento u otra. Un trabajo visualmente atractivo puede no representar el mismo alcance ni haber sido ejecutado íntegramente por el equipo que presenta la propuesta.
Pedí los roles del equipo asignado, interlocutor, disponibilidad y participación de terceros. La trayectoria general de una empresa no reemplaza saber quién hará el trabajo y cómo se cubren cambios de disponibilidad.
Finalmente, exigí una propuesta económica desglosada: moneda, impuestos, vigencia, pagos, facturación, opcionales, recurrentes y terceros. No compares el total hasta confirmar que las propuestas incluyen las mismas filas y condiciones.
Cómo normalizar presupuestos web en Argentina y LATAM
Para comparar propuestas de distintos países o modelos de contratación, no conviertas importes sin documentar las reglas. Registrá la moneda y el país de facturación, qué impuestos están incluidos o excluidos, qué comprobante se emite y hasta cuándo tiene vigencia la oferta.
Si existe ajuste cambiario, pedí que se indique la referencia, la base y el momento de aplicación. Separá implementación de licencias, hosting, plugins, APIs, servicios de terceros, soporte y mantenimiento. Identificá qué conceptos son únicos, cuáles recurrentes y quién contrata cada servicio.
Una fórmula conceptual útil es:
Costo total del primer año = implementación + costos recurrentes del período + licencias y servicios de terceros + soporte o mantenimiento elegido.
No reemplaza una revisión contable o legal. Sirve para llevar todas las propuestas al mismo período y hacer visibles sus supuestos. Compará también hitos y cronograma de pagos, condiciones de salida y jurisdicción contractual.
Para cada propuesta (A, B y C) anotá:
- Moneda y país de facturación
- Impuestos incluidos/excluidos y comprobante
- Vigencia de la oferta
- Regla, base y momento de ajuste cambiario
- Implementación inicial
- Licencias, hosting, plugins, APIs y terceros
- Soporte y mantenimiento
- Cronograma de pagos e hitos
- Condiciones de salida y jurisdicción
- Costo total del primer año
Qué hacer cuando los alcances no coinciden
Construí un alcance base con los requisitos obligatorios y pedí que cada proveedor confirme su estado. Mové las mejoras no esenciales a opcionales, pedí aclaración para todo lo no especificado y anotá dependencias por separado.
No completes silencios por inferencia. Si una propuesta no menciona carga de contenido, redirecciones o licencias, registralo como no especificado hasta recibir confirmación escrita. Compará el mismo período y distinguí diferencias de alcance de diferencias comerciales. Recién después evaluá el costo normalizado.
Podés copiar esta estructura para los 12 criterios:
Por cada criterio, registrá estado + evidencia en A, B y C:
- Diagnóstico
- Alcance
- Proceso
- UX, contenido y accesibilidad
- Tecnología
- SEO técnico y migración
- Performance y seguridad
- Medición
- Propiedad y portabilidad
- QA y aceptación
- Publicación y continuidad
- Evidencia, equipo y condiciones
En cada celda usá uno de los cuatro estados —incluido / excluido / opcional / no especificado— y agregá una nota o referencia al documento que lo respalda.
Preguntas que convierten una respuesta vaga en verificable
Una buena respuesta oral ayuda, pero pedí que su contenido quede incorporado a la propuesta, el alcance o un anexo. Estas seis preguntas suelen exponer diferencias relevantes:
- ¿Qué entregable deja el diagnóstico y quién lo aprueba? Buscá actividades, participantes, insumos, resultado y validación; no sólo “hacemos discovery”.
- ¿Dónde termina el alcance y qué activa un adicional? La respuesta debería cubrir límites, revisiones, cambios sobre aprobaciones y dependencias.
- ¿Qué condiciones deben cumplirse para aceptar cada etapa? Pedí criterios observables, responsable de aprobación y tratamiento de incidencias.
- ¿Qué activos controla el cliente y qué recibe al finalizar la relación? Esperá un inventario, titulares, accesos, formatos y restricciones.
- ¿Qué acciones quedarán medidas y cómo se probarán? Deben aparecer eventos, validación, cuentas y responsables, no sólo una herramienta.
- ¿Qué ocurre después de publicar? Separá garantía, soporte, mantenimiento, backups, actualizaciones y costos.
SEO
- Respuesta vaga: “SEO incluido”
- Respuesta verificable: Entregables de lanzamiento, responsables, aceptación y tratamiento de cambios de URL.
Performance
- Respuesta vaga: “El sitio será rápido”
- Respuesta verificable: Métricas, datos, condiciones de prueba, momento de medición y responsable de corrección.
Propiedad
- Respuesta vaga: “El sitio es tuyo”
- Respuesta verificable: Inventario de activos, titulares, accesos, formatos de entrega y condiciones de salida.
Soporte
- Respuesta vaga: “Incluye soporte”
- Respuesta verificable: Canal, horario, alcance, prioridad, respuesta y separación entre garantía y mantenimiento.
Red flags que justifican pausar y pedir aclaraciones
Una red flag abre una verificación; salvo que afecte un requisito obligatorio, no implica descartar automáticamente. Conviene pausar cuando:
- se recomienda una solución antes de comprender objetivos y restricciones;
- el alcance usa adjetivos, pero no identifica entregables, límites o responsables;
- varios criterios quedan como no especificado y se presume que estarán incluidos;
- se garantizan rankings, tráfico u otros resultados fuera del control del entregable;
- dominio, repositorio, analítica u otras cuentas críticas quedan bajo control exclusivo no explicado;
- los costos recurrentes y servicios de terceros no aparecen desglosados;
- QA, accesibilidad o soporte se declaran sin cobertura ni aceptación;
- el portfolio no permite atribuir qué parte hizo el proveedor;
- una tecnología se presenta como fin en sí mismo, sin vincularla con la operación;
- existe presión para decidir antes de responder aclaraciones por escrito.
¿Agencia, freelancer o plataforma autogestionada?
Ningún modelo es universalmente superior. Comparalos según la complejidad del alcance, las capacidades necesarias, la coordinación, la autonomía interna, las integraciones, la continuidad y el mantenimiento esperado.
- Agencia: Roles incluidos, coordinación entre especialidades, equipo efectivamente asignado, interlocución y continuidad.
- Freelancer: Alcance que puede cubrir, red de colaboradores, disponibilidad, reemplazos, documentación y soporte posterior.
- Plataforma autogestionada: Capacidad interna para configurar, producir contenidos, integrar, probar, mantener y resolver límites de la plataforma.
Aplicá la misma matriz a las tres opciones. Un proveedor local tampoco es mejor por definición que uno remoto: compará horarios, idioma, coordinación, facturación, jurisdicción y modalidad de soporte según tus necesidades.
Preguntas frecuentes
¿Cómo saber si una agencia de diseño web es buena?
Evaluá su adecuación al proyecto, no adjetivos ni un portfolio aislado. Buscá evidencia atribuible, alcance claro, responsables identificados, criterios de aceptación, control de activos y condiciones de continuidad. Una opción puede ser adecuada para un proyecto y no para otro.
¿Qué debe incluir un presupuesto de diseño web?
Debería detallar alcance, entregables, exclusiones, supuestos, responsables, hitos, revisiones, aceptación, condiciones económicas, costos de terceros, propiedad y pospublicación. También debe distinguir qué está incluido, excluido, opcional o no especificado.
¿Conviene una agencia local?
No necesariamente. La ubicación es una variable operativa: revisá horarios, coordinación, idioma, facturación, jurisdicción y soporte. Un equipo remoto que documenta bien estos puntos puede ajustarse al proyecto; uno local también debe explicitarlos.
¿Conviene una plantilla, un CMS o desarrollo a medida?
Depende de la edición requerida, permisos, personalización, integraciones, mantenimiento, licencias y portabilidad. Pedí una demostración del flujo habitual y compará restricciones. La marca de la tecnología no reemplaza la adecuación al uso.
¿SEO y mantenimiento deberían estar incluidos?
Ambos términos necesitan alcance. En SEO, separá la base técnica y la migración del eventual servicio continuo. En continuidad, distinguí garantía por defectos, soporte correctivo y mantenimiento preventivo o evolutivo. Pueden estar incluidos, excluidos u ofrecidos como opcionales, pero no deberían quedar sin especificar.
Checklist final para tomar la decisión
Antes de elegir, comprobá que:
- clasificaste cada necesidad como obligatoria, preferencia o no aplica;
- los 12 criterios tienen estado incluido / excluido / opcional / no especificado;
- cada promesa relevante se convirtió en entregable, evidencia y aceptación;
- están identificados los responsables del cliente, proveedor y terceros;
- las dependencias y los supuestos quedaron por escrito;
- dominio, cuentas, código, contenidos, datos y accesos tienen titular y condición de salida;
- QA, publicación, garantía, soporte y mantenimiento tienen alcance diferenciado;
- normalizaste moneda, impuestos, recurrentes, terceros y costo total del primer año;
- todas las dudas críticas fueron respondidas en documentación contractual.
La opción más defendible es la que cumple los requisitos obligatorios y deja menos supuestos críticos sin resolver, no la que obtiene un promedio artificial. Si estás armando o revisando un alcance, podés contrastar estos criterios con la forma de trabajo de nuestra agencia de diseño y desarrollo web.
