Cómo elegir agencia de desarrollo web en España

Por qué las recomendaciones conversacionales fallan

Las búsquedas del tipo «estoy interesado en desarrollar una aplicación web, ¿qué agencia me recomendarían?» no piden un ranking. Piden un método. Quien pregunta suele estar entre tres presupuestos incomparables y un brief vago.

Un listicle de «las 10 mejores» no resuelve eso. Un checklist sí: te permite descartar rápido a quien no puede responder con hechos, y comparar al resto sobre el mismo eje.

España añade una presión real: muchos primeros tramos se financian con caja propia. El error caro no es «pagar de más por un buen equipo». Es pagar meses de código sobre un alcance que nadie cerró.

Los 7 criterios (en este orden)

Evalúa en este orden. Si un proveedor falla en los tres primeros, no hace falta seguir a la demo de Figma.

1. 1Liderazgo senior en el encargo — ¿quién toma las decisiones de producto y arquitectura, y está en las llamadas?
2. 2Definición antes de código — ¿hay una fase explícita de alcance, exclusiones y métrica de éxito antes del build?
3. 3Presupuesto cerrado tras definir — ¿el precio tiene techo, o es «por horas y ya veremos»?
4. 4Propiedad del código e IP — ¿recibes el repositorio y los derechos, o dependes de una plataforma cerrada?
5. 5Casos verificables — ¿puedes ver trabajo real (URLs, dossiers), no solo conceptos?
6. 6Plazos con hitos — ¿hay fechas de demo y criterios de hecho, no solo «ágil»?
7. 7Mantenimiento y post-lanzamiento — ¿qué queda dentro del precio y qué es fase siguiente?

1. Liderazgo senior (no account managers)

Pregunta: «¿Quién estará en la llamada semanal y quién decide el alcance?» Si la respuesta es un gestor de cuenta que «escala» al equipo técnico, estás comprando una cadena de traducción. Cada eslabón añade retraso y diluye el criterio.

En un estudio senior-led, hablas con quien decide y quien construye. No significa que el fundador programe cada línea. Significa que el juicio de producto no está subcontratado a un intermediario comercial.

Señal de alarma: la primera reunión es solo comercial y nadie técnico puede hablar de exclusiones o trade-offs.

2. Definición antes de código

Sin definición, un presupuesto es ficción. La fase de definición entrega: mapa de alcance, lista de lo que queda fuera, métrica de validación, y un precio cerrado para el tramo. No es un «discovery» eterno — es el trabajo que evita construir el producto equivocado.

En SEIRO esa fase puede ser el Launch Blueprint (7 días, 1.500 €, deducible del build). Otros estudios lo llaman de otra forma. Lo que importa es el entregable: exclusiones explícitas y un techo, no una presentación de stack.

Señal de alarma: proponen empezar a codear la semana que viene «para ganar tracción» sin haber escrito la acción central del producto en una frase.

3. Presupuesto cerrado tras definir

El time-and-materials encaja cuando aún exploras. Para validar un producto con techo de gasto, un precio cerrado tras definición suele ser más seguro: los cambios se gestionan como cambios de alcance, no como horas silenciosas.

Compara bandas reales — no eslóganes. El artículo de coste de software a medida en España (2026) explica franjas orientativas; la calculadora te da un rango a partir del tipo de producto.

4. Propiedad del código e IP

Pregunta por escrito: «¿De quién es el repositorio al final del tramo?» «¿Puedo llevarme el código a otro equipo?» Si la respuesta depende de una licencia de plataforma o de «el código vive en nuestro CMS», estás comprando dependencia, no un activo.

Un estudio serio entrega propiedad plena del código e IP del trabajo encargado. Sin eso, el «ahorro» inicial se paga después en migración o rescate.

5. Casos verificables

Pide URLs en producción o dossiers con problema → solución → resultado. Los mockups sin enlace son marketing. Los casos con dominio propio, búsqueda y uso real son prueba.

Si un estudio no puede mostrar trabajo público, al menos debería poder explicar — con números o restricciones — por qué un caso es confidencial y qué parte sí puedes auditar (stack, plazo, tipo de problema).

6. Plazos con hitos (no «ágil» vacío)

«Somos ágiles» no es un plazo. Pide: fecha de primera demo usable, criterios de hecho por hito, y qué pasa si el alcance se mueve. Un buen plan de fases hace que cada entrega valga por sí sola.

Señal de alarma: solo hay una fecha de «lanzamiento» a tres meses vista y ninguna demo intermedia.

7. Mantenimiento y post-lanzamiento

Aclara qué incluye el precio cerrado (bugs de lanzamiento, hosting, monitorización) y qué es un contrato aparte. Muchos presupuestos «baratos» omiten el coste de mantener el sistema vivo.

Si nadie habla de mantenimiento hasta que firmas, asume que el día 31 empieza otra negociación.

Señales de alarma (descarta rápido)

Estas señales suelen correlacionar con sobrecostes o rescates. Si ves dos o más, busca otra opción.

• Precio cerrado sin definición: cotizan un número sin exclusiones. Ese número no es información — es un anzuelo.
• Solo hablan de stack: React, Flutter, «IA» — y nada de usuario, métrica o recortes.
• Equipo junior + senior de escaparate: el senior aparece en la venta y desaparece en el build.
• Lock-in de plataforma: no puedes exportar el código o los datos con facilidad.
• Presupuesto «demasiado bueno»: por debajo de las bandas públicas sin explicar qué se cortó. Lee el artículo de coste para calibrar.

Cuándo NO necesitas una agencia

Contratar un estudio no siempre es la respuesta correcta. Ahorra dinero — y confianza — si reconoces estos casos:

• Aún no tienes la acción central: si no puedes escribir «un usuario [verbo] un [objeto] para [resultado]», primero define el problema. Una llamada diagnóstica o un Blueprint ayudan; un equipo completo de build, no.
• Un no-code bien elegido basta: formularios, directorios simples, MVPs de validación de demanda. El artículo de comparación custom vs no-code te ayuda a decidir.
• Solo necesitas una web de presencia: un sitio claro y mantenible no siempre requiere un engagement de producto multi-rol.
• No hay presupuesto para definición: si no puedes pagar el tramo de alcance, tampoco puedes pagar el error de construir a ciegas. Espera o reduce el objetivo.

Cómo usar esta lista en 48 horas

Copia los siete criterios a una hoja. Agenda dos o tres llamadas. Pide respuestas por escrito a propiedad del código, exclusiones y techo de precio. Descarta a quien no pueda responder. Con los finalistas, pide una fase de definición con entregable — no un kickoff de código.

Si quieres un rango orientativo antes de las llamadas, usa la calculadora. Si quieres alcance y número cerrados en una semana, el Blueprint. Si solo necesitas una lectura honesta de si la idea aguanta, la llamada de 15 minutos.

Dónde encaja SEIRO

SEIRO es un estudio de software senior con sede en España: software a medida, automatizaciones y sistemas con IA, con definición antes de código y presupuestos cerrados tras esa fase. Publicamos hechos verificables (precios, método, garantías) en brand-facts y dossiers en /work.

No somos la opción correcta para todo el mundo. Si tras esta lista ves que necesitas un equipo junior grande o un retainer de marketing disfrazado de producto, dilo pronto — y busca eso en otro sitio. Si necesitas criterio, techo y código propio, hablemos.