Ayer a las 10pm tenía una idea vaga sobre convertir un deployment de Directus en un activo de ventas. Esta mañana a las 7am tenía un admin funcional en Railway, tres dashboards en vivo, un blog público demo con cinco posts, una página pilar de ventas de 2,400 palabras que presenta la forma completa como un servicio, y tres bugs de producción que atrapé y arreglé a medianoche. El costo total de infraestructura: $5 por mes. El tiempo total: aproximadamente nueve horas de trabajo enfocado distribuidas en una noche y una madrugada.
Este es el caso de estudio. Qué se construyó, qué se rompió, qué aprendí, y los números reales detrás del build. Si estás evaluando si encargar un proyecto similar para tu negocio, los puntos de datos a continuación son la referencia más honesta que puedo ofrecer.
Qué me propuse hacer
Tres objetivos, en orden de prioridad.
Primero, desplegar Directus conectado a mi base de datos Postgres de Supabase existente. Objetivo: un admin CRUD genérico apuntando a los mismos datos que mi admin Astro personalizado ya gestiona. Razón: no reemplazar el admin personalizado (que tiene edición en línea estilo Monday que al equipo le gusta), sino agregar la capa de operaciones que el admin personalizado no tiene. Ediciones masivas, vistas guardadas, permisos basados en roles, navegador de esquema, dashboards Insights.
Segundo, configuré los dashboards que he querido durante seis meses. Tres tableros: pipeline de contenido (velocidad de publicación de blogs, profundidad de la cola de temas), salud SEO (posiciones de ranking, tasa de presencia en AI Overview, distribución de intenciones), uso de herramientas (búsquedas de herramientas AEO, búsquedas de herramientas de marca, uso de asesor). Números concretos que pueda ver de un vistazo los lunes para saber si el motor está funcionando.
Tercero, convertí todo el build en un activo de ventas. El admin de Directus que depliego para mí es idéntico al que desplegaría para un cliente. Así que el deployment en sí se convierte en la demo. Un cliente potencial hace clic en un botón en mi página de ventas, llega a un admin de Directus real poblado con datos reales, escribe en el editor de texto enriquecido, ve cómo funcionan las vistas guardadas, y luego regresa para reservar una llamada. Fricción total del demo-loop: aproximadamente quince segundos desde que llega a la página hasta el editor en vivo.
Hora 0 a 4: deploy
Plan hobby de Railway, plantilla oficial de Directus, deploy de un clic. La plantilla viene con Directus más Redis más una base de datos PostGIS agrupada más un bucket de almacenamiento compatible con S3. Tiempo total de deploy incluyendo configuración: 35 minutos desde una cuenta Railway en blanco hasta el admin con sesión iniciada.
La primera sorpresa: la plantilla de Directus conecta su base de datos mediante variables de referencia que apuntan al servicio PostGIS agrupado, no mediante campos individuales de host/puerto/usuario/contraseña. Para redirigir Directus a mi Postgres externo de Supabase, necesitaba encontrar la variable de cadena de conexión (DB_CONNECTION_STRING) y pegar mi URL de Supabase Session pooler con credenciales.
La segunda sorpresa: mi contraseña de base de datos de Supabase contenía el carácter "#". Codificado como %23 en una cadena de conexión Postgres. Sin codificación, el parser de URL corta la cadena en el # porque hash significa fragmento de URL. Directus registró ECONNREFUSED::1:5432 porque retrocedió a localhost cuando la cadena de conexión estaba malformada. Media hora de confusión, luego rotéé la contraseña a solo alfanumérico y la conexión se estableció.
Una vez que Directus se conectó, todas las 12 tablas de mi base de datos de Supabase se importaron automáticamente como Colecciones de Directus. Cero migración de esquema, cero movimiento de datos, cero tiempo de inactividad. El admin de Astro personalizado y el admin de Directus ven los mismos datos, ambos escriben en él, ambos reflejan inmediatamente los cambios del otro.
Hora 4 a 12: configurar, configurar, configurar
El grueso del trabajo no fue el deployment. Fue la configuración a nivel de campo para hacer que Directus se comportara como un admin pulido en lugar de un navegador de base de datos crudo. Cada columna necesita metadatos de interfaz, formato de visualización, orden de clasificación, ancho, grupo y decisiones de visibilidad. Directus por defecto muestra todo; la versión pulida muestra solo lo que el equipo necesita.
Tres observaciones de esta fase.
Hacer esto a través de la interfaz de administración de Directus clickeando es lento. Aproximadamente dos minutos por campo, noventa-más campos distribuidos entre doce colecciones, tiempo total de clicks cerca de tres horas. Delegué en un agente de IA que controla el navegador (Claude en Chrome) que cambió a la API REST de Directus para configuración en lote. El agente publicó llamadas PATCH /fields/{collection}/{field} en secuencia, con el objeto meta completo como payload. Tres minutos por colección en lugar de cuarenta. Toda la fase de configuración se comprimió de tres horas a cuarenta minutos.
El enfoque de API REST también me dio reproducibilidad. Cada PATCH es un equivalente de curl que podría re-ejecutar en un despliegue nuevo de Directus para restaurar la misma configuración. La configuración es efectivamente código, no un montón frágil de clicks de interfaz.
El último cuarto de esta fase fue construir los tres dashboards de Insights. Cada panel es una configuración JSON enviada a POST /panels. Los dashboards se pusieron en marcha en aproximadamente veinte minutos una vez que los metadatos de campo estuvieron en su lugar. Tres tableros, seis paneles, datos reales renderizándose. Los números que había estado adivinando durante seis meses finalmente aparecieron en pantalla.
Hora 12 a 18: los tres bugs que más tiempo tomaron
Ninguna construcción es real hasta que falla en producción. Tres bugs surgieron después de que desplegué a main y refresqué el sitio en vivo.
Bug 1: escena de Spline bloqueada por CSP, con tres causas apiladas
También había desplegado un pilar web 3D-first con un robot héroe NEXBOT de Spline. Después del despliegue, el robot era invisible en producción pero funcionaba localmente. Tres problemas apilados en secuencia.
Uno: la etiqueta de script usando define:vars fue inlineada por Astro, lo que significaba que Vite no agrupaba la importación dinámica de @splinetool/viewer, lo que significaba que el especificador de módulo desnudo no se resolvía en el navegador. Dos: después de arreglarlo, el elemento spline-viewer estaba dentro de un padre con el atributo hidden en el momento de la actualización, así que el elemento personalizado Lit se inicializó con dimensiones 0x0 y nunca se recuperó. Tres: después de arreglarlo, el visor Spline obtiene su WASM de modelado desde unpkg.com en el tiempo de carga de escena, que mi CSP no tenía en la lista blanca. Cada arreglo hizo emerger el siguiente bug. Tiempo total de depuración: noventa minutos.
La depuración solo en producción es su propia disciplina. El servidor de desarrollo resuelve importaciones desnudas diferente que la compilación de producción. El ambiente de desarrollo tiene una CSP predeterminada más permisiva. Ambos bugs eran imposibles de surfacear sin un despliegue en producción real. Mi conclusión: despliega en un ambiente real temprano, incluso cuando lo local funciona bien.
Bug 2: booleano de AI Overview y avg() de Postgres
Un panel de Insights quería mostrar "qué porcentaje de ejecuciones SERP rastreadas muestran una AI Overview." La tabla seo_serp_runs tiene una columna booleana ai_overview_present. Instinto ingenuo: promediar esa columna, multiplicar por 100, renderizar como porcentaje.
Postgres falla con avg(boolean). La función no existe para ese tipo. Varios intentos de solución fracasaron: Directus no expone un agregado "percentage", contar verdaderos con denominador hardcodeado se desvía conforme llegan más filas, castear en tiempo de consulta no está expuesto a través de las opciones del panel de Insights.
La solución que funcionó: añadir una columna generada ai_overview_present_int que calcula como case when ai_overview_present then 100 else 0 end. avg() sobre una columna entera funciona trivialmente y arroja el porcentaje directamente. Una migración SQL de una línea, cero cambio de código de la aplicación.
Bug 3: hosts de imagen en CSP
Sembré el blog de demostración con cinco URLs de fotos de Unsplash. El navegador las bloqueó silenciosamente porque images.unsplash.com no estaba permitido en img-src. Imágenes de tarjeta negras sólidas en el blog de demostración público. Añadí Unsplash a CSP, las imágenes se renderizaron, luego me di cuenta de que acababa de violar mi propia regla innegociable sobre usar FAL para todas las imágenes almacenadas en Supabase Storage.
Solución correcta: un script que extrae cada fila demo_posts, genera una fotografía editorial por categoría mediante FAL flux-pro/v1.1-ultra, sharp recodifica a WebP con calidad 82 ancho máximo 1600, carga a un bucket público de Supabase Storage, actualiza featured_image a la URL del CDN de almacenamiento. Compilación de veinte minutos, cinco generaciones FAL cuestan menos de una libra. Removí Unsplash de CSP. Las imágenes ahora viven en mi propia infraestructura, sin dependencias externas, sin carrera de actualización de CSP-por-host en adelante.
Hora 18 a 24: el pilar de ventas
Con Directus funcionando y el blog de demostración renderizándose correctamente, escribí el pilar de ventas en /solutions/headless-cms-and-admin-tools/. Cuatro niveles de servicio (CMS, admin de operaciones internas, directorios, a medida), con precios en USD y GBP entre paréntesis, seis preguntas frecuentes, una tabla de comparación contra WordPress y HubSpot y Notion y Airtable, una sección "brief que no aceptaré" para descalificar a los clientes de forma equivocada al principio.
El pilar vincula directamente a la demostración en vivo. Los prospectos que hacen clic en "OPEN THE EDITOR" llegan al admin de Directus real con credenciales mostradas que pegan. Segundos después están editando un post real en un editor real. El bucle de demostración es de quince segundos desde la llegada a la página hasta la edición en vivo.
Tiempo total en la página del pilar: noventa minutos de escritura más treinta minutos de schema markup, enlaces internos y pulido visual. La página en sí tomó menos tiempo que dos de los tres bugs.
Números
Desglose de costos de construcción, ya que este es el artículo de caso de estudio y esa es la pregunta que harán los prospectos.
Plan Railway Hobby para Directus + Redis + bucket: $5 por mes, facturado mensualmente. Primeros 30 días gratis.
Supabase Postgres: infraestructura existente, sin costo nuevo. Usando el plan Pro ya en aproximadamente $25 por mes para la base de datos.
FAL API para cinco imágenes hero: menos de una libra en total, aproximadamente $1 USD.
DataForSEO para rellenar 42 palabras clave con volumen de búsqueda + intención + dificultad: $0.04 en total.
Mi tiempo, de principio a fin incluyendo los bugs y la redacción: nueve horas de trabajo enfocado. A mi tarifa diaria de consultoría de aproximadamente $1,500 por día, eso es aproximadamente $1,700 en costo de oportunidad.
Desembolso en efectivo total para lanzar el activo de ventas funcional: aproximadamente $6 en infraestructura marginal más $1 en tarifas de API. Costo real total incluyendo tiempo: aproximadamente $1,700.
Comparación de referencia: una agencia cotizando un proyecto de "construcción de herramienta administrativa de CMS headless" típicamente cobraría $8,000 a $15,000 USD por el alcance equivalente. Yo cobro $8,000 a $19,000 USD en mi propia página de servicios. La brecha entre costo de construcción y precio de venta es todo el motor económico del trabajo de agencia. El caso de estudio es la prueba de que el número de costo de construcción es real.
Lo que esto demuestra a un cliente prospectivo
Tres cosas, todas verificables en los próximos diez minutos.
Primero, la construcción es real. Haz clic en el botón OPEN THE EDITOR en la página de ventas. Escribe en el editor de texto enriquecido. Programa una publicación. Mira los dashboards. La cosa existe. No es un mockup, no es un archivo de Figma, no es una captura de pantalla. Es el mismo software que desplegaría para tu negocio.
Segundo, la velocidad es real. Veinticuatro horas desde "idea vaga" hasta "activo de ventas desplegado en producción con demostración en vivo". Un engagement con cliente no se movería a esta velocidad porque los engagements con clientes incluyen descubrimiento, revisión de diseño, aprobaciones de stakeholders y auditorías de seguridad. Pero la velocidad de construcción subyacente es lo que determina si una línea de tiempo de seis semanas es honesta u optimista. Veinticuatro horas de esfuerzo de construcción en solitario corresponden aproximadamente a tres semanas de tiempo de engagement de agencia estándar una vez que se incluye el overhead. Esa matemática es la que produce la línea de tiempo de nivel 1 de seis a ocho semanas.
Tercero, los modos de falla son reales. Tres bugs de producción fueron capturados y corregidos en tiempo real. Problemas de CSP, bundling de importación dinámica, aritmética de columnas generadas. Estos son los mismos bugs que surgen en los engagements con clientes. El hecho de que los haya capturado y resuelto en un sitio en vivo es la demostración real de competencia. Un case study pulido sin bugs sería el sospechoso.
Lo que haría diferente
Tres pequeñas reflexiones, en orden de utilidad.
Habría comenzado con el script de generación de imágenes de FAL antes del workaround de Unsplash. El dance de actualización-y-reversión de CSP costó diez minutos de churn innecesario. La regla innegociable sobre imágenes de FAL existe exactamente por esta razón y debería haberla escuchado primero.
Habría usado el enfoque de REST API para la configuración de Directus desde el inicio en lugar de intentar el click-through de la UI. La secuencia de llamadas REST impulsada por agente fue tres veces más rápida y produjo configuración reproducible. La lección se generaliza más allá de Directus: cualquier admin que exponga una REST API integral debe ser configurado a través de esa API en lugar de a través de su UI.
Habría escrito el post de case study más pronto. Este post se está escribiendo aproximadamente doce horas después de que terminó la construcción. Para el momento en que estoy escribiendo esto, algunos de los modos de falla ya están desapareciendo de la memoria. El case study honesto es el que se escribe dentro del mismo día que la construcción, mientras los bugs son lo suficientemente frescos para describirlos con precisión.
A dónde ir después
Si estás evaluando si tu empresa debería contratar un proyecto similar, el demo interactivo es el camino más rápido hacia una respuesta útil. Abre /solutions/headless-cms-and-admin-tools/, haz clic en el botón de demostración, inicia sesión con las credenciales que se muestran, dedica quince minutos a explorar. Al final tendrás una idea clara de si esta clase de herramienta se ajusta a tu equipo o no.
Si es así, agenda la llamada de treinta minutos que aparece vinculada en esa página. Cuéntame tu stack actual, el tamaño de tu equipo, la estructura de tus datos. Al final de la llamada tienes una selección de nivel, un rango de precio y una ventana de entrega. La mayoría de los proyectos que asumo duran de seis a doce semanas con un costo de $8,000 a $50,000 USD dependiendo del alcance. La mitad que no asumo, te explico por qué en la llamada.
Si quieres el pitch de ventas completo, la página principal está en /solutions/headless-cms-and-admin-tools/. Si quieres ir directo al demo en vivo, las credenciales están en esa página. Si quieres el próximo caso de estudio, el próximo artículo de blog probablemente trate sobre un proyecto de fabricante en el corredor asiático o el mismo patrón aplicado a un vertical diferente. Dime cuál te es más útil.