Cada proyecto de cliente cuesta la misma cantidad de tiempo — ya sea el primero o el quincuagésimo. Después de 20 formularios de contacto idénticos, 20 configuraciones SEO idénticas y 20 despliegues idénticos en Vercel, me pregunté: ¿Estoy construyendo sitios web, o estoy construyendo un sistema que construye sitios web?

La respuesta cambió mi modelo de negocio.

La trampa de tiempo-por-dinero en el desarrollo web freelance

El desarrollo web freelance tiene un problema fundamental de escalabilidad: el 80% de los requisitos son idénticos en cada proyecto.

Formulario de contacto. SEO local. Navegación optimizada para móvil. Contenido multiidioma. Marcado Schema.org. Banner de cookies. Aviso legal. Política de privacidad. Google Analytics. Sitemap. Despliegue rápido.

El 20% restante es personalizado: branding, contenido específico, quizás algunas funciones custom.

Pero construyes desde cero cada vez.

Las matemáticas son brutales: Un proyecto típico de sitio web para PYME cuesta 40-60 horas de desarrollo. A una tarifa de $20-30 USD/hora (promedio para freelancers experimentados en Latinoamérica), son $800-1,800 USD por proyecto. Suena bien — hasta que te das cuenta de que con 5 proyectos al mes, estás trabajando 250 horas. Eso es 62.5 horas por semana.

No escalable. No sostenible. No inteligente.

La pregunta no es si puedes trabajar más rápido. La pregunta es si puedes cambiar el sistema.

La arquitectura: Plantillas standalone + generador con shell script

Decidí no usar WordPress. No porque WordPress sea malo — está construido para editores de contenido que quieren trabajar sin desarrolladores. Mi objetivo era diferente: quería desplegar rápido como desarrollador, sin costos mensuales de hosting para clientes, sin mantenimiento de base de datos, sin actualizaciones de plugins.

¿Por qué Astro?

Astro es static-first. Eso significa: sin base de datos, sin costos de servidor, sin vulnerabilidades de seguridad por plugins desactualizados. El output es HTML, CSS y JavaScript puro. Puntajes de Lighthouse de 95+ son estándar, no excepción.

La arquitectura de componentes es perfecta para bloques de plantillas. Un <ContactForm>, un <ProductGrid>, un <HeroSection> — todo reutilizable, todo con tipos seguros, todo versionado.

¿Por qué un shell script en lugar de un generador no-code?

Porque el objetivo no es una app — el objetivo es control.

El script son 200 líneas de Bash. Es legible, versionable, extensible. Sin suscripción SaaS, sin vendor lock-in, sin costos mensuales. Puedo ejecutarlo en 5 años sin preocuparme de que una startup quiebre.

./create-customer-project.sh

# Preguntas:
# - ¿Industria? (Panadería, Restaurante, Consultoría, Blog)
# - ¿Mercado? (MX, CO, AR, CL, PE, UY, PY, BO, EC, VE, ES, ...)
# - ¿Dominio?
# - ¿Color primario?

# Output:
# → Proyecto Astro completo
# → Localización (14 mercados: DACH + Latinoamérica)
# → Configuración SEO (Schema.org, Sitemap, Meta tags)
# → Textos legales (Aviso legal, Privacidad, específicos por país)
# → Repositorio GitHub
# → Despliegue en Vercel
# → URL en vivo en 5 minutos

El trade-off: Sin editor visual. Tienes que tocar código. Pero: Tienes control total. Sin caja negra. Sin limitaciones.

Para mí como desarrollador, ese es el trade-off correcto. Para alguien que nunca quiere escribir código, WordPress es la mejor opción.

Lo que construí que no funcionó

La primera versión tenía imports @shared.

Pensé: ¿Por qué debería duplicar el mismo <Button> en 5 plantillas? Construiré un paquete @shared/components, y todas las plantillas importarán de ahí.

El problema: Los proyectos de clientes generados tenían dependencias.

Un cliente quería hacer self-hosting. Clonó el proyecto, ejecutó npm install — y obtuvo un error. El paquete @shared no estaba disponible públicamente. Build roto.

La solución: Las plantillas son completamente standalone.

Cada plantilla contiene todos los componentes, todos los estilos, todas las utilidades. Sin imports externos. Cuando generas un proyecto de cliente, es un proyecto Astro completo y autocontenido. Puedes subirlo a GitHub, desplegarlo en Vercel, hostearlo en tu propio servidor — funciona en todas partes.

El trade-off: Duplicación de código. El mismo <Button> existe 5 veces. Pero: Seguridad de despliegue. Ningún cliente tendrá un build roto porque falta una dependencia.

Esa es la diferencia entre “funciona en mi máquina” y “funciona en todas partes”.

Pastelería 2001: La prueba de que funciona en producción

El primer proyecto real de cliente fue una panadería mexicana en Morelia, Michoacán.

Los requisitos:

  • 28 productos en 3 categorías (Pan Dulce, Pasteles, Galletas)
  • Precios en MXN (pesos mexicanos)
  • Completamente localizado (es-MX, español mexicano — sin “vosotros” europeo)
  • Optimizado para móvil (80% de los clientes navegan en celular)
  • Desplegado en Vercel

La implementación:

./create-customer-project.sh
→ Industria: Panadería
→ Mercado: México (MX)
→ Dominio: pasteleria2001.mx
→ Color primario: #D4845A (terracota cálido)

5 minutos después: URL en vivo, Lighthouse Score 98/100 Performance, completamente funcional.

Lo que esto probó: No es solo un concepto. Está desplegado, está funcionando, tiene un cliente real. Y ese cliente está en México — el mercado que mejor conozco.

Lo que el sistema no resuelve (todavía)

Quiero ser honesto: Esto no es un CMS.

Limitaciones:

  • Sin editor visual para clientes. Las actualizaciones de contenido requieren conocimiento de Git o mi ayuda.
  • Sin integración de e-commerce. Catálogos de productos sí, flujo de checkout no.
  • Sin autenticación de usuarios. Páginas estáticas, sin áreas de login.

Por qué eso está bien: El público objetivo son pequeñas empresas que necesitan presencia, no una tienda en línea. Panaderías, artesanos, consultores, restaurantes. Necesitan un sitio web que muestre sus servicios, que se encuentre en Google, que funcione en celular.

Para todo lo demás, está Shopify, WooCommerce, o desarrollo custom.

Qué sigue: La integración de CMS está planeada. Probablemente Decap CMS (antes Netlify CMS) — basado en Git, sin backend, gratis. Pero eso es el post 5 de esta serie.

Cómo la arquitectura standalone previene el infierno de dependencias

El próximo post va a los detalles técnicos: Por qué las plantillas standalone son mejores que los componentes compartidos, cómo el script generador maneja 14 mercados con un comando, y por qué las Content Collections de Astro son el modelo de datos perfecto para sistemas de plantillas.

Este artículo es la parte 1 de la serie “Website Factory — cómo construí un negocio web escalable desde plantillas”.

Sobre el autor: Daniel es solopreneur y desarrollador web, basado en Berlín, opera en los mercados DACH y Latinoamérica. Construye sistemas, no proyectos individuales.