La velocidad en la era de la IA: cómo construí tres productos en semanas

Durante mucho tiempo, el camino desde la idea de un producto hasta su lanzamiento en producción fue una maratón. Si eras un desarrollador en solitario, construir un producto de software significaba comprometerte con semanas de configuración repetitiva: configurar bases de datos, montar la autenticación, escribir endpoints de enrutamiento de la API, construir layouts responsivos y escribir scripts de validación.

Para cuando llegabas al momento de programar el núcleo de tu propuesta de valor única, ya estabas agotado.

Pero a mediados de 2026, la velocidad de construcción ha cambiado de raíz. En un periodo de cuatro semanas, diseñé, construí y lancé tres aplicaciones web distintas:

1. SentryPost: un programador automático de publicaciones en redes sociales que optimiza las horas de envío a partir de los registros de interacción de la audiencia.
2. Tabulate: una utilidad de base de datos que analiza recibos en PDF y vuelca sus partidas directamente en hojas de gastos estructuradas.
3. DailyList: un agregador minimalista de newsletters que resume las actualizaciones diarias por correo en un único panel.

No soy un desarrollador 10x, y no escribí este software trabajando semanas de 100 horas. Lo que hice fue usar un stack estandarizado (Next.js, TailwindCSS y Supabase) y delegar todo el código repetitivo, el layout y la lógica de integración a agentes de programación con IA.

Esta es una retrospectiva sobre el flujo de trabajo, la arquitectura y las lecciones de desarrollo que aprendí construyendo a la velocidad del pensamiento.

---

El stack estandarizado: un plano para la velocidad

Para construir rápido con IA, tienes que eliminar la variedad arquitectónica. Si cambias de proveedor de base de datos, de framework de backend o de enfoque de CSS entre proyectos, tus agentes de programación con IA se confundirán. Mezclarán convenciones, y eso dispara los errores de compilación.

Estandaricé un único stack limpio para los tres productos:

• Framework: Next.js (App Router, TypeScript)
• Estilos: TailwindCSS (para maquetar rápido con clases utilitarias)
• Base de datos y autenticación: Supabase (PostgreSQL con autenticación por correo integrada)
• Despliegues: Vercel (para despliegues de vista previa automáticos)

+-------------------------------------------------+
| Next.js App Router (TypeScript)                 |
|                                                 |
| [Frontend UI: Tailwind]  <-->  [Backend API]    |
|                                     |           |
|                               (Supabase Client) |
|                                     v           |
|                              [Supabase DB /     |
|                               Authentication]   |
+-------------------------------------------------+

Al mantener el stack idéntico, el contexto del modelo se mantuvo alineado en todos los proyectos. Podía reutilizar esquemas de base de datos, wrappers de cliente y guardas de autenticación de un repositorio a otro. Cuando abría la terminal de un proyecto nuevo y decía «Configura los wrappers del cliente de autenticación de Supabase», la IA generaba exactamente los wrappers que encajaban con las convenciones de mi código anterior.

---

Etapa 1: borrador del esquema y configuración de la base de datos

El primer cuello de botella al lanzar una app es el diseño de la base de datos. Antes de escribir cualquier interfaz, tienes que definir tablas, claves y relaciones de claves foráneas.

En lugar de escribir SQL a mano, diseñé los esquemas de la base de datos con simples tablas en markdown. Por ejemplo, para SentryPost redacté esta descripción:

Tablas:
- users: id (uuid), email (text), tier (text)
- schedules: id (uuid), user_id (ref users), title (text), content (text), send_at (timestamp), status (enum)
- metrics: id (uuid), schedule_id (ref schedules), impressions (int), clicks (int)

Le pasé esta tabla a mi agente de terminal y ejecuté la siguiente consulta: claude -p "Genera los scripts de migración de PostgreSQL para Supabase que coincidan con esta definición de esquema. Incluye políticas de seguridad a nivel de fila (RLS) que permitan a los usuarios leer y escribir solo sus propios datos."

En cuestión de segundos, el agente generó el SQL de la migración:

-- Crear la tabla schedules
CREATE TYPE schedule_status AS ENUM ('draft', 'scheduled', 'sent', 'failed');

CREATE TABLE public.schedules (
    id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
    user_id UUID REFERENCES auth.users(id) ON DELETE CASCADE NOT NULL,
    title TEXT NOT NULL,
    content TEXT NOT NULL,
    send_at TIMESTAMP WITH TIME ZONE NOT NULL,
    status schedule_status DEFAULT 'draft'::schedule_status NOT NULL,
    created_at TIMESTAMP WITH TIME ZONE DEFAULT timezone('utc'::text, now()) NOT NULL
);

-- Activar la seguridad a nivel de fila
ALTER TABLE public.schedules ENABLE ROW LEVEL SECURITY;

-- Crear la política para SELECT
CREATE POLICY "Users can view their own schedules" 
    ON public.schedules FOR SELECT 
    USING (auth.uid() = user_id);

-- Crear la política para INSERT
CREATE POLICY "Users can insert their own schedules" 
    ON public.schedules FOR INSERT 
    WITH CHECK (auth.uid() = user_id);

Al generar los archivos de migración y las políticas RLS en un solo prompt, me ahorré horas de escribir SQL a mano. Las RLS tienen fama de ser difíciles de escribir a mano sin errores de sintaxis, pero la IA, entrenada con miles de configuraciones de Supabase, resolvió las políticas correctamente.

---

Etapa 2: diseño rápido de la interfaz con Tailwind y Flexbox

Una vez configurada la base de datos, pasé a la interfaz de usuario. Diseñar layouts desde cero puede ser un proceso lento, sobre todo cuando hay que ajustar el flex wrap, las proporciones del padding y las clases del modo oscuro.

Usé un enfoque de «borrador de layout». Escribí una descripción semántica del layout de la interfaz:

Crea un layout base del panel para SentryPost.
- Barra lateral: elementos de navegación (Dashboard, Schedules, Analytics, Settings). Tarjeta de perfil en la parte inferior.
- Área principal: encabezado con migas de pan y botón 'Create New'.
- Cuadrícula: 3 tarjetas de métricas (Scheduled Posts, Sent Posts, Success Rate %).
- Lista: una lista de datos limpia que muestre las publicaciones programadas con insignias de estado.

Le pasé esta petición de layout a la IA y me devolvió un componente de React muy optimizado con la estructura de layout en Tailwind. Al describir qué debía aparecer en la pantalla en lugar de cómo escribir las clases de CSS, dejé que la IA se encargara de los ajustes del layout.

Si la alineación de un botón se veía mal, no me ponía a buscar reglas de flexbox en CSS. Simplemente seleccionaba el bloque en mi editor y pedía: «Alinea este botón al extremo derecho de la tarjeta, centrado en vertical, con la misma altura que el input de al lado». La IA actualizaba las clases utilitarias de Tailwind al instante.

---

Estrategia práctica para construir rápido

Si quieres construir y lanzar productos a esta velocidad, tienes que cambiar tus hábitos de desarrollo:

• Usa un repositorio boilerplate: no ejecutes create-next-app desde cero en cada proyecto. Mantén un repositorio de plantilla privado que ya tenga inicializados la configuración del cliente de autenticación de Supabase, los componentes de navegación estándar, los hooks de pago y los layouts de metadatos.
• Prueba pronto las operaciones de base de datos: antes de escribir la interfaz, escribe scripts locales para insertar y leer registros de prueba. Comprueba que las restricciones, los esquemas y las rutas de la API funcionan antes de construir los formularios visuales.
• Evita la sobreingeniería: no implementes cachés complejas, sistemas de colas ni clústeres escalables en tu MVP. Usa triggers de SQL básicos, cron jobs sencillos y filas normales de la base de datos para guardar las colas hasta que hayas validado la demanda de los clientes.
• Itera con feature flags: si una funcionalidad es difícil de terminar, envuélvela en un feature flag o desactiva el enlace en la interfaz. Céntrate primero en lanzar el ciclo principal.

---

Perspectivas de futuro: la startup del solopreneur

En el futuro, el coste del desarrollo de software seguirá acercándose a cero.

Un solo desarrollador que entienda la arquitectura de sistemas y las necesidades de los clientes podrá construir y gestionar un portafolio de aplicaciones web que antes requería una startup respaldada por capital riesgo. La ventaja competitiva en tecnología se desplazará de la capacidad de programar hacia el conocimiento del mercado, la validación con clientes y los canales de distribución.

El desarrollador de éxito del futuro no será quien escriba a mano los bucles de código más limpios; será quien sepa identificar problemas, diseñar sistemas y dirigir agentes de IA para construir soluciones estables en tiempo récord.

---

Enlaces internos

• Para ver cómo las herramientas de agentes nativas de la terminal agilizan los cambios en varios archivos, echa un vistazo a Claude Code vs Cursor: análisis a fondo de quien construye con ambos.
• Aprende a estandarizar tus adaptadores de base de datos y de API en MCP será el USB-C de las aplicaciones de IA.
• Para mantener limpio el código de tu repositorio y evitar errores de compilación durante el desarrollo rápido, consulta Cómo validar el código de la IA: 8 principios para desarrolladores en solitario.

Referencias externas

• Revisa la configuración de bases de datos y las pautas de RLS en el Supabase Documentation Blog.
• Explora layouts de página y la optimización de despliegues en el Vercel Blog.
• Lee sobre prototipado rápido y velocidad de desarrollo de software en el GitHub Blog.

---

Lo que cambió mi perspectiva

Antes creía que fundar una empresa de software exigía un cofundador, una ronda de financiación semilla y meses de iteraciones de ingeniería. Pasé todo 2023 escribiendo documentos de diseño para una idea de SaaS, debatiendo sobre frameworks y optimizando un modelo de base de datos local que nunca vio a un solo usuario real. Estaba paralizado por la complejidad de la ejecución.

Cuando empecé mi experimento de 4 semanas, me comprometí a construir solo con un stack preconfigurado y a dejar que mis agentes de programación escribieran el código. Me obligué a lanzar cada app en cuanto funcionara el flujo principal del usuario, aunque la página de ajustes estuviera vacía.

Ver mi primer producto en producción en Vercel tras solo seis días de desarrollo cambió por completo mi visión del mundo. Usuarios reales empezaron a registrarse, a enviar comentarios y a pedir funcionalidades.

Me di cuenta de que el código que escribimos en nuestros editores es solo un detalle de implementación; el valor está en el ciclo entre el feedback de los usuarios y las actualizaciones del producto. Al dejar que la IA se ocupara de los detalles de ejecución, dejé de comportarme como un formateador de editor y empecé a actuar como product owner. En un mes lancé más código que en los dos años anteriores y, por primera vez en mi vida, estaba construyendo en tiempo real.