¿Por qué una agencia de desarrollo no tenía su propio sitio web?
Hay una ironía particular en ser una agencia de desarrollo que no tiene su propio sitio web. Durante meses, trabajamos en proyectos increíbles para nuestros clientes - desde plataformas SaaS complejas hasta e-commerce con miles de productos - pero nuestro propio sitio era... inexistente.
El problema no era falta de habilidad técnica. Era el clásico dilema del zapatero: estábamos tan ocupados haciendo zapatos para otros que andábamos descalzos.
Hasta que un día dijimos: "Basta. Vamos a construir nuestro sitio, y lo vamos a hacer bien."
Esta es la historia de cómo nandark.com pasó de ser una idea en un Notion doc a una realidad en producción en menos de dos semanas, y todas las lecciones que aprendimos en el camino.
Conclusión: De la Idea a la Realidad
Esta fue nuestra historia. No perfecta, pero real. Como desarrolladores, sabemos que el código es solo una parte. El verdadero desafío es ejecutar, iterar y lanzar.
Si quieres profundizar en cómo escalar aplicaciones SaaS con Next.js y Vercel, te puede interesar nuestro análisis completo del stack.
En Nandark, aplicamos estas lecciones en cada proyecto de desarrollo. Conversemos sobre tu próximo lanzamiento.
¿Qué stack tecnológico elegimos y por qué?
Para nosotros, la elección del stack fue casi obvia. Trabajamos día a día con estas tecnologías en proyectos de clientes, así que sabíamos exactamente qué queríamos:
Next.js 15 + App Router
Por qué: Next.js es nuestra herramienta de elección para prácticamente todo. La versión 15 con App Router nos da:
- Server Components por defecto (mejor performance)
- Metadata API nativa (SEO sin librerías externas)
- Turbopack para builds ultra-rápidos
- Optimización de imágenes automática
El trade-off: Next.js 15 era relativamente nuevo cuando empezamos. Esto significaba que algunas librerías aún no estaban completamente compatibles. Spoiler: nos encontraríamos con esto más adelante.
Velite para el contenido del blog
Por qué: Necesitábamos una forma de gestionar el contenido del blog sin montar un CMS completo. Velite nos permite escribir posts en Markdown con frontmatter, y los compila a datos tipados en build time.
La alternativa: Consideramos Contentlayer, pero su desarrollo se había ralentizado. Velite era activamente mantenido y tenía mejor TypeScript support.
Tailwind CSS v4
Por qué: ¿Diseño moderno sin escribir CSS vanilla? Sí, por favor. Además, la versión 4 tiene mejoras de performance significativas.
El reto: Tailwind v4 cambió la arquitectura de plugins. Algunos plugins antiguos no funcionaban. Tuvimos que adaptar nuestro approach.
Vercel para hosting
Por qué: La sinergia entre Next.js y Vercel es imbatible. Preview deployments en cada push, edge functions, analytics incorporado. Es difícil justificar cualquier otra cosa para un sitio Next.js.
¿Cómo definimos el diseño y la estética visual?
El diseño fue donde pasamos más tiempo del esperado. No por falta de ideas, sino por exceso de ellas.
La Estética: Cyber Minimalismo
Queríamos algo que reflejara nuestra filosofía: "Tu éxito, nuestra sombra." Trabajamos en la sombra, somos el socio invisible que hace que las cosas funcionen. Esto se tradujo en:
- Paleta oscura: Negro profundo con acentos cyan y violet
- Glassmorphism: Elementos con backdrop-blur para ese efecto "flotante"
- Animaciones sutiles: Orbs animados en el fondo, hover effects suaves
- Tipografía bold: Espacios en blanco generosos, jerarquía clara
El Sistema de Diseño
Creamos un sistema de colores y componentes reutilizables desde el inicio:
/* Gradientes signature */
.gradient-primary {
background: linear-gradient(to right, theme('colors.cyan.400'), theme('colors.violet.400'));
}
/* Cards con glassmorphism */
.glass-card {
backdrop-filter: blur(12px);
background: linear-gradient(to bottom right, rgba(255,255,255,0.05), rgba(255,255,255,0.02));
border: 1px solid rgba(255,255,255,0.1);
}
Este sistema nos permitió mantener consistencia visual en todas las páginas sin escribir CSS repetido.
¿Qué errores cometimos y cómo los solucionamos?
Error #1: Dependency Hell con Tailwind v4
El problema: Tailwind v4 cambió cómo funcionan los plugins. Específicamente, @tailwindcss/typography que usábamos para estilizar el contenido del blog.
El síntoma: Build fallaba en Vercel con errores crípticos sobre módulos no encontrados.
La solución: Instalar explícitamente @tailwindcss/typography@0.5.19 como dependencia y configurarlo correctamente en globals.css:
@import "tailwindcss";
@plugin "@tailwindcss/typography";
Lección aprendida: Cuando uses versiones bleeding-edge de tecnologías, siempre verifica la compatibilidad de todas las dependencias antes de hacer deploy.
Error #2: El Misterio del .velite Import
El problema: Nuestro sitemap.ts importaba datos de @/.velite, pero este directorio se genera en build time. En Vercel, el build fallaba con "Module not found: Can't resolve '@/.velite'".
El debugging: Pasamos horas intentando entender por qué funcionaba localmente pero no en Vercel. Resulta que Turbopack maneja los module paths diferente que Webpack.
La solución: En lugar de importar desde .velite, cambiamos a leer los archivos markdown directamente usando fs y gray-matter:
// ❌ Fallaba en build
import { posts } from '@/.velite';
// ✅ Funciona siempre
const postsDirectory = path.join(process.cwd(), 'content/blog');
const fileNames = fs.readdirSync(postsDirectory);
const posts = fileNames.map(fileName => {
const fileContents = fs.readFileSync(path.join(postsDirectory, fileName), 'utf8');
const { data } = matter(fileContents);
return data;
});
Lección aprendida: Los imports mágicos son convenientes hasta que no lo son. Cuando tengas problemas de build, vuelve a las basics: filesystem operations siempre funcionan.
Error #3: Dependencies Faltantes en Vercel
El problema: Dos builds consecutivos fallaron porque faltaban dependencias críticas que funcionaban localmente.
Build #1 falló: Faltaban rehype-slug y rehype-pretty-code, usados por Velite para procesar el markdown.
Build #2 falló: Faltaba @tailwindcss/typography para los estilos del blog.
Por qué pasó: Estas dependencias estaban instaladas globalmente en nuestra máquina de desarrollo, pero no en package.json.
La solución:
npm install rehype-slug rehype-pretty-code @tailwindcss/typography --save
Lección aprendida: Siempre prueba tu build en un ambiente limpio antes de hacer deploy a producción. Mejor aún: configura CI que haga builds en cada push.
¿Cómo estructuramos el contenido del sitio?
Una de las decisiones más importantes fue cómo estructurar el contenido del sitio.
Case Studies: Real vs Confidencial
Teníamos un dilema: habíamos hecho proyectos increíbles para clientes, pero muchos tenían NDAs. ¿Cómo mostrar nuestra experiencia sin violar confidencialidad?
La solución: Un sistema híbrido:
- 7 proyectos públicos con información completa: challenge, solution, results, testimonials
- 5 proyectos confidenciales con una página placeholder elegante
Para los proyectos confidenciales, creamos un template que dice: "Este proyecto está bajo NDA, pero está en producción y generando valor real." Con un diseño profesional (lock icon, glassmorphism card, animated orbs) que transmite credibilidad sin revelar detalles.
const placeholderCases = [
'healthcare-automation',
'ecommerce-redesign',
'edtech-platform',
'crm-custom-development',
'logistics-dashboard'
];
// En el component:
if (placeholderCases.includes(slug)) {
return <ConfidentialTemplate />;
}
Blog: Technical + Narrative
Decidimos que nuestro blog necesitaba dos tipos de contenido:
- Guías técnicas: Deep dives en tecnologías, código, mejores prácticas (como nuestra guía de SEO en Next.js)
- Stories narrativas: Behind-the-scenes, aprendizajes, filosofía (como este post)
Esta mezcla atrae tanto a desarrolladores buscando soluciones técnicas como a founders evaluando con quién trabajar.
¿Qué implementamos para SEO técnico?
No íbamos a lanzar un sitio sin SEO técnico impecable. Implementamos:
robots.txt Optimizado
Con reglas específicas para:
- Googlebot y Bingbot (permitido)
- Scrapers de IA (bloqueado)
- Archivos internos de Next.js (bloqueado)
sitemap.xml Dinámico
Que incluye automáticamente:
- Todas las páginas estáticas
- Todos los posts del blog (excluyendo drafts)
- Todos los case studies (12 total)
Con priorities estratégicas:
- Homepage: 1.0
- Secciones principales: 0.9
- Contenido específico: 0.7-0.8
- Páginas legales: 0.3
Metadata Completa
Cada página tiene:
- Title y description únicos
- OpenGraph tags para compartir en redes
- Canonical URLs
- Structured data (JSON-LD)
Puedes ver los detalles de implementación en nuestra guía completa de SEO.
¿Cómo fue nuestro proceso de deploy?
Nuestro flujo de trabajo fue:
- Desarrollo local con
npm run dev - Commit a feature branch
- Push a GitHub
- Vercel auto-deploy a preview URL
- Review en preview
- Merge a main si todo está OK
- Auto-deploy a producción
Este flujo nos permitió iterar rápidamente. En promedio, desde que teníamos una idea hasta verla en producción pasaban menos de 30 minutos.
El Día del Launch
El día que finalmente hicimos merge a main y el sitio fue live fue... anticlimático. Y eso es exactamente lo que queríamos.
No hubo bugs de último minuto. No hubo downtime. No hubo "oh no, olvidamos configurar X."
Porque habíamos usado los preview deployments de Vercel para testear exhaustivamente cada feature antes de mergear. Cuando llegó el momento del launch, ya sabíamos que todo funcionaba.
¿Qué métricas obtuvimos al final?
Algunos números interesantes:
- Tiempo total de desarrollo: ~2 semanas (part-time)
- Commits totales: 147
- Líneas de código: ~8,500 (incluyendo content)
- Páginas totales: 44 (generadas estáticamente)
- Performance (Lighthouse):
- Performance: 98
- Accessibility: 100
- Best Practices: 100
- SEO: 100
- Build time: ~8.8 segundos
- Bundle size (First Load JS): 140 kB
¿Qué haríamos diferente si empezáramos de nuevo?
Si empezáramos de nuevo hoy:
- Configurar CI desde el día 1 - Habríamos detectado las dependencias faltantes antes
- Escribir tests para los componentes críticos - No lo hicimos por velocidad, pero nos habría dado más confianza
- Documentar decisiones técnicas en el momento - Tuvimos que reconstruir el contexto para escribir este post
¿Qué hicimos muy bien en este proyecto?
- Usar tecnologías que conocíamos profundamente - No experimentamos con stack nuevo
- Preview deployments religiosamente - Cada feature fue testeada en condiciones de producción antes de mergear
- Sistema de diseño temprano - Los componentes reutilizables aceleraron el desarrollo masivamente
- Priorizar SEO desde el inicio - No fue un afterthought, fue parte del foundation
¿Qué lecciones puedes aplicar a tu próximo proyecto?
Si estás a punto de lanzar un sitio (o app), estas son las lecciones que queremos que te lleves:
1. La Configuración Técnica No Es Negociable
No importa qué tan bonito sea tu diseño o qué tan revolucionario sea tu producto - si Google no puede rastrearlo, si tus builds fallan aleatoriamente, si tu sitio es lento... nada más importa.
Invierte tiempo en:
- SEO técnico (robots.txt, sitemap.xml, metadata)
- Performance (optimización de imágenes, code splitting)
- Configuración de deploy (CI/CD, environment variables)
2. Los Preview Deployments Son Un Game Changer
La capacidad de ver cada cambio en un ambiente de producción real antes de mergear es transformacional. Vercel lo hace trivial, pero el concepto aplica a cualquier plataforma.
3. El Contenido Es Parte de la Arquitectura
No pienses en "primero construimos el sitio, después agregamos contenido." El contenido debe influir en la arquitectura desde el día uno.
Nuestro sistema de case studies (público vs confidencial) surgió de entender nuestras limitaciones de contenido early on.
4. Documenta Tus Errores
Los errores son oro puro para aprendizaje. Cada error que documentamos (como el issue de .velite import) es un problema que otro desarrollador no tendrá que sufrir.
¿Qué sigue para Nandark.com?
Este sitio no es un proyecto "terminado" - es un producto vivo que seguirá evolucionando:
En el roadmap:
- Implementar búsqueda full-text en el blog
- Agregar newsletter subscription funcional
- Crear laboratorio interactivo para experimentos
- Mejorar animaciones y micro-interactions
- Integrar analytics más profundos
Conclusión: Construir en Público
Lanzar nandark.com fue más que crear un sitio web. Fue un statement: practicamos lo que predicamos.
Cuando le decimos a un cliente "Next.js 15 con Vercel es el stack ideal para tu SaaS", no es marketing. Es experiencia real, ganada a través de builds, deploys, y los inevitables errores que vienen con ellos.
¿Quieres Lanzar Tu Proyecto con Este Stack?
Este es exactamente el proceso que seguimos con nuestros clientes. Si estás pensando en lanzar un sitio web, app o SaaS, podemos ayudarte a:
- Evitar los errores que cometimos
- Configurar el stack correcto desde el día uno
- Lanzar en semanas, no meses
Servicios relacionados
- Desarrollo Web con Next.js: Sitios como este, para tu empresa
- Desarrollo de Producto SaaS: De MVP a producto escalable
- Optimización y Core Web Vitals: Mejora la velocidad de tu sitio existente
Conversemos sobre tu proyecto: Respuesta en 24 horas.
Agradecimientos especiales a las herramientas que hicieron esto posible: Next.js, Vercel, Tailwind CSS, Velite, y la increíble comunidad open-source que construye estas tecnologías.
