¿Qué tipo de sitio para qué objetivo?
Un cliente nos llamó recientemente. Quería “un sitio como Amazon, pero para su panadería”. Presupuesto: 2.000€. Plazo: dos semanas.
No es una broma. Es nuestro día a día.
Y detrás de este desfase hay una pregunta real que muchos empresarios no saben formular: ¿qué tipo de sitio corresponde realmente a lo que quiero lograr?
Porque construir un sitio sin responder primero a esta pregunta es como pedir una furgoneta para hacer ciclismo de montaña. Se mueve. Pero no hacia donde quieres ir.
Así es como abordamos esta elección con nuestros clientes, tras 15 años de proyectos en Normandía y más allá.
Sitio vitrina: cuando la presencia es suficiente
La mayoría de las microempresas no necesitan un monstruo técnico. Necesitan ser encontradas, tranquilizar al visitante y convertirlo en una llamada telefónica o en una solicitud de presupuesto.
Un sitio vitrina bien construido — 5 a 7 páginas, rápido, mobile-first, SEO-ready — hace ese trabajo. Nada más, nada menos.
Lo que nuestras auditorías muestran regularmente: artesanos con un sitio vitrina sobrio y bien posicionado que generan más leads que una pyme con un portal de 50.000€ mal optimizado. La tecnología nunca compensa la estrategia — y nuestros servicios de creación de sitios siempre parten de esta lógica de encuadre.
Tienda online: cuando la transacción es el centro
¿Vendes productos? La pregunta no es “¿WooCommerce o PrestaShop?” — volveremos a eso. La verdadera pregunta es: ¿tu modelo de negocio justifica la inversión en una tienda online?
Un comerciante con 30 referencias y una clientela local fiel no tiene las mismas necesidades que un distribuidor con 8.000 SKUs e integraciones ERP. Ambos pueden necesitar una tienda. Pero no la misma.
En los proyectos de e-commerce que hemos realizado, el criterio número uno de éxito no es la plataforma elegida. Es la claridad del recorrido de compra y la calidad de la ficha de producto. El resto es fontanería — importante, pero secundaria.
Aplicación de negocio o SaaS: cuando el sitio se convierte en herramienta
Este es el tercer tipo, a menudo mal comprendido. Ya no es un “sitio” en el sentido tradicional — es un software accesible a través del navegador. Gestión de reservas, área de cliente, panel de control de negocio, flujo de trabajo automatizado.
Aquí, las decisiones arquitectónicas tomadas al inicio te acompañarán durante años. Y es precisamente aquí donde los proyectos que integran IA comienzan a revelar sus fragilidades.
La deuda técnica invisible: el verdadero riesgo de los proyectos de IA
Aquí es donde se pone interesante — y donde pocas agencias hablan con franqueza.
Durante 18 meses, hemos integrado IA en nuestras propias herramientas de producción (Nova Mind, nuestro pipeline de contenido automatizado) y en los proyectos de algunos clientes. Y aprendimos una lección a las malas: la IA no solo crea valor. También crea deuda técnica invisible.
¿Qué significa esto concretamente?
Cuando integras un modelo de lenguaje o un componente de IA en tu arquitectura, introduces una dependencia que se comporta de forma diferente a las dependencias clásicas. Una base de datos — sabes lo que hace. ¿Una llamada API a un modelo de IA? El comportamiento puede cambiar según la versión del modelo, el contexto de la solicitud, la carga del proveedor, las actualizaciones unilaterales del proveedor.
Esto no es razón para no integrar IA. Es razón para hacerlo con método.
Dónde se esconden las deudas arquitectónicas ligadas a la IA
Primer escollo: el acoplamiento fuerte con un único proveedor.
Vemos proyectos enteros construidos sobre la hipótesis de que la API de OpenAI estará siempre disponible, siempre al mismo precio, con la misma interfaz. Es una bomba de relojería. Si has conectado directamente tus llamadas GPT-4 a tu lógica de negocio sin capa de abstracción, un cambio de precio o de modelo puede exigir una refactorización parcial.
La buena práctica: una capa de abstracción entre tu código y el proveedor de IA. ¿Cambias de modelo? Modificas un archivo de configuración, no 40 funciones.
Segundo escollo: los prompts sin versionar.
Tus prompts son código. Si los almacenas en una interfaz gráfica, en un Google Doc, o peor — en la cabeza del desarrollador que montó el proyecto — tienes un problema grave de mantenibilidad.
En Nova Mind, todos nuestros prompts están versionados en Git, con pruebas de regresión sobre los outputs críticos. Cuando modificamos un prompt de generación de artículo, sabemos exactamente qué cambió y por qué.
Tercer escollo: la ausencia de monitorización de los outputs de IA.
Un bug clásico lo ves: la aplicación cae, los logs se disparan, el error es visible. Un bug de IA es diferente. La aplicación funciona. Las respuestas llegan. Pero su calidad se degrada progresivamente, o se vuelven incoherentes en ciertos casos límite.
Sin monitorización específica de los outputs de IA, no lo sabrás hasta que tus usuarios se quejen. Es también por esto que defendemos una arquitectura local-first centrada en una UX humana: menos dependencias opacas, más control sobre lo que ve el usuario.
Construir para durar: los principios que resisten
Tras 15 años construyendo sitios “a mano” y ahora industrializando con IA, esto es lo que no ha cambiado: los buenos fundamentos de arquitectura siguen siendo los mismos, con IA o sin ella.
Lo que cambia es su importancia relativa.
Separación de responsabilidades
En todo proyecto digital — vitrina, e-commerce o aplicación IA — la regla básica sigue siendo: cada componente debe tener una responsabilidad única y claramente definida.
Tu componente de generación de contenido IA no debe también gestionar la caché, la autenticación y el envío de correos. Si lo hace, tienes un problema de diseño que la IA amplificará, no resolverá.
Lo que vemos concretamente en clientes que integraron herramientas de IA con urgencia, sin arquitectura previa: sistemas que funcionan en demo, y que se derrumban en la primera subida de carga o el primer cambio de proveedor.
Reversibilidad de las decisiones técnicas
“Las buenas decisiones de arquitectura son las que puedes deshacer sin reconstruirlo todo.”
Es el principio que aplicamos sistemáticamente en nuestros proyectos. Antes de elegir una tecnología o un proveedor, nos preguntamos: si hay que salir de esto en 18 meses, ¿cuánto cuesta?
Para la IA, esto significa: no escribir lógica de negocio en tus prompts. No almacenar estado crítico únicamente en un sistema de IA. No construir flujos de trabajo que solo puedan funcionar con un modelo específico.
Observabilidad desde el principio
En los proyectos sin IA, la observabilidad (logs, métricas, alertas) se añade a menudo a posteriori. Ya es una mala práctica. Con IA, es una falta profesional.
Necesitas saber, en tiempo real: cuántas llamadas de IA haces, a qué coste, con qué tasa de éxito, con qué latencia. Y cuando un output de IA se usa para tomar una decisión de negocio, debes poder trazarlo.
En Nova Mind, monitorizamos cada generación de artículo: modelo utilizado, tokens consumidos, tiempo de respuesta, puntuación de calidad estimada. No por amor a las cifras — para detectar derivas antes de que se conviertan en problemas.
Las 3 preguntas a hacer antes de lanzar tu proyecto digital
Independientemente de si construyes un sitio vitrina o una aplicación de IA compleja, estas tres preguntas deben tener respuestas claras antes de escribir la primera línea de código — o de firmar el primer presupuesto.
1. ¿Cuál es el resultado medible esperado en 6 meses?
No “tener un sitio bonito”. No “estar presente en internet”. Un resultado concreto: X leads por mes, Y% de conversión en el carrito, Z horas ahorradas en un proceso de negocio. Si no puedes responder a esta pregunta, el proyecto no está listo.
2. ¿Cuáles son las dependencias críticas de tu arquitectura?
Para cada componente tecnológico: ¿qué pasa si desaparece o cambia de precio en 12 meses? Esta pregunta es incómoda. Es indispensable. La aprendimos por las malas en un proyecto donde una herramienta de automatización cambió sus condiciones tarifarias de un día para otro — y nuestro cliente dependía totalmente de esa herramienta.
3. ¿Cómo vas a mantener y hacer evolucionar este sistema?
Un sitio entregado no es un sitio terminado. Es un sistema vivo que necesitará actualizaciones, correcciones, evoluciones. ¿Quién se encarga? ¿Con qué presupuesto? ¿Según qué proceso? Los proyectos que fracasan a largo plazo generalmente no están mal construidos — están mal mantenidos.
Lo que esto cambia concretamente para tu proyecto
Según un estudio de McKinsey sobre los proyectos de transformación digital, más del 70% de los proyectos no alcanzan sus objetivos iniciales. No es cuestión de presupuesto ni de tecnología. Es cuestión de método y claridad de objetivos.
Las pymes que tienen éxito en sus proyectos digitales comparten un punto en común: se tomaron el tiempo de encuadrar antes de construir. No durante meses — bastan unos días. Pero ese encuadre existe, y vale tanto para un sitio vitrina como para un proyecto que anticipa los cambios que trae la IA.
Si estuviera en tu lugar, esto es lo que haría antes de empezar cualquier proyecto:
- Definir el tipo de sitio adaptado a tu objetivo real (no a tu idea inicial)
- Identificar los 3 riesgos arquitectónicos principales, especialmente si integras IA
- Establecer un método de medición de resultados desde el primer día
No es glamuroso. No es viral. Pero es lo que marca la diferencia entre un proyecto que aporta valor y uno que rehaces en 18 meses.
Construir rápido y construir bien: los dos no se oponen
Entregamos sitios en 3 a 7 días con nuestro flujo de trabajo industrializado. Algunos clientes piensan que velocidad = sacrificio en calidad o rigor arquitectónico.
Es lo contrario.
Somos rápidos porque las decisiones estructurales se toman de antemano. Porque nuestro stack está probado. Porque no reinventamos la fontanería en cada proyecto.
Y en los proyectos que integran IA, dedicamos el tiempo adicional necesario para establecer las capas de abstracción correctas, versionar los prompts, poner en marcha la monitorización. No por perfeccionismo — por pragmatismo. Porque el coste de una deuda técnica mal gestionada en un sistema de IA es muy superior a las pocas horas invertidas desde el principio.
Tu proyecto digital merece ser construido para durar, no solo para ser entregado.
Si quieres que auditemos tu arquitectura actual, o que encuadremos juntos tu próximo proyecto — sitio vitrina, e-commerce o aplicación con IA — contacta con GDM-Pixel. Te diremos qué funciona, qué no funciona, y qué haríamos en tu lugar. Sin rodeos.