El Problema Real: 3 AM y Sin Fontanero
Todo empezó con un mensaje de WhatsApp a las 3 de la mañana. Mi hermana tenía una tubería rota, agua corriendo por el salón, y necesitaba un fontanero *ahora*.
Hizo lo que hace todo el mundo: Google "emergency plumber near me". Encontró un sitio de 2003 con números de teléfono que no respondían. Llamó a otro. Cerrado. El tercero le cobró $400 por venir y mirar.
En ese momento pensé: "Aquí hay un problema que alguien tiene a las 3 AM, dispuesto a pagar, y no puede solucionarlo fácilmente".
Eso es oro en el mundo de los startups.
La Idea: Simple, Pero ¿Viable?
Mi primer instinto fue hacer una app móvil con notificaciones push. Incluso empecé a diseñar la interfaz.
Luego me paré y pensé diferente.
¿Quién busca fontaneros de emergencia? Gente asustada en Google. No descargan apps. No crean cuentas. Quieren un número de teléfono en 10 segundos.
¿Cuál es el mejor lugar para estar? En la primera página de Google cuando alguien busca "emergency plumber in Los Angeles" a las 2 AM.
Eso cambió todo. No necesitaba una app. Necesitaba SEO.
La Estrategia: 1,104 Páginas Estáticas
La estrategia fue brutal en su simplicidad:
1. 90 ciudades principales en Estados Unidos 2. 1,251 fontaneros verificados con ratings de calidad 3. Una página estática por ciudad optimizada para SEO 4. Generación estática en build time = velocidad máxima + ranking garantizado
En lugar de construir dinámicamente, usé Next.js 16 con App Router para generar todas las páginas en el build. Esto significa:
- **Cero latencia**: Las páginas están pre-renderizadas en Vercel
- **SEO perfecto**: Google ve HTML estático, no JavaScript
- **Caché infinito**: Una página generada nunca cambia (hasta que redeploy)
```typescript // Ejemplo de cómo generé las rutas dinámicamente export async function generateStaticParams() { const cities = await getCitiesFromSupabase(); return cities.map((city) => ({ slug: city.slug, })); }
export default async function CityPage({ params }) { const plumbers = await getPlumbersByCity(params.slug); return <CityTemplate plumbers={plumbers} />; } ```
La magia: 1,104 páginas generadas en menos de 5 minutos. Una sola vez. Luego Vercel las sirve desde CDN global.
El Stack: Elegí Herramientas, No Complejidad
Mucha gente hubiera elegido Elasticsearch, Redis, microservicios. Yo elegí:
- **Next.js 16**: Para generación estática y React 19
- **Supabase (PostgreSQL)**: Una base de datos SQL simple. Sin NoSQL, sin complicaciones
- **Sanity CMS**: Para el blog (porque SEO también necesita contenido)
- **Tailwind CSS 4**: Styling sin pensar
- **TypeScript strict mode**: Porque los errores en producción no son diversión
Por qué esta combinación:
- Supabase es 10x más barato que Firebase
- Sanity me permite escribir artículos sin tocar código
- Todo corre en Vercel (deployment automático desde Git)
- TypeScript strict me atrapa bugs antes de que los usuarios los vean
Los Problemas Reales (Y Cómo Los Resolví)
Mi último commit fue el 27 de diciembre. Aquí están los problemas que encontré:
Problema 1: Google No Indexaba
Generé 1,104 páginas. Google indexó 47.
La razón: canonicals rotos y redirects de www. Google pensaba que había contenido duplicado.
Fix:
```typescript // next.config.js const config = { async redirects() { return [ { source: '/:path*', destination: 'https://www.findemergencyplumber.com/:path*', permanent: true, has: [ { type: 'host', value: 'findemergencyplumber.com', }, ], }, ]; }, }; ```
Después de esto, Google indexó 1,089 páginas en dos semanas.
Problema 2: Las Imágenes del Blog Rompían Todo
Usé Sanity para el contenido del blog. Sus imágenes venían con URLs especiales. Vercel intentaba optimizarlas y fallaba con errores 402.
Solución: Deshabilité la optimización de imágenes para URLs de Sanity.
```typescript // next.config.js const config = { images: { unoptimized: process.env.NODE_ENV === 'production', }, }; ```
No es elegante, pero funciona. A veces pragmatismo > perfección.
Problema 3: Conflictos de CSS en Tailwind
Los utilities `py-*` conflictaban con `.container`. Pasé 2 horas buscando por qué los paddings no funcionaban.
Fix: Usé `padding-inline` en lugar de `px-*`.
```css .container { padding-inline: 1rem; } ```
Detalles estúpidos que consumen tiempo real.
Los Números (Reales)
- **1,104 páginas estáticas generadas**
- **1,251 fontaneros verificados** en la base de datos
- **90 ciudades cubiertas**
- **Build time: 4-5 minutos**
- **Página load: < 1 segundo** (desde CDN)
- **Google indexó: 1,089 páginas**
En términos de ingresos: Cada fontanero paga una suscripción mensual por estar en el directorio. El modelo es simple: más fontaneros = más ingresos.
La Lección Más Importante
Mucha gente vería este proyecto y pensaría: "Necesito una app móvil, API REST, push notifications, machine learning".
Yo pensé: "¿Dónde está mi usuario cuando necesita esto? En Google. ¿Qué es lo más rápido de construir? Páginas estáticas".
La mejor tecnología es la que resuelve el problema real del usuario, no la que parece impresionante en GitHub.
Next.js + Supabase + Sanity + Vercel. Cuatro herramientas. Una visión clara. 1,104 páginas indexadas.
Qué Viene Ahora
Tengo dos caminos:
1. Expansión SEO: Agregar 200 ciudades más, escribir 300 artículos de blog 2. Integración Twilio: Agregar un sistema SMS/Call para conectar directamente fontaneros con clientes (este era el plan original, pero resulta que el SEO es más valioso)
Por ahora, estoy en el camino 1. Los números me dicen que el SEO funciona mejor que cualquier app.
---
Takeaway
Si tienes una idea pero piensas que necesitas tecnología compleja para validarla:
No la necesitas.
Yo validé Find Emergency Plumber con páginas estáticas. Sin API, sin mobile app, sin notificaciones push.
Piensa en dónde está tu usuario. Luego ve allí con la herramienta más simple que funcione.
A veces eso es Webflow. A veces es Next.js. A veces es un Google Sheet compartido.
Lo que importa es que resuelve el problema.
Todo lo demás es ruido.