marketyour.games: web comercial en C, CGI y SQLite

Un producto comercial que cabe en la cabeza de una persona

Un solo binario, un archivo SQLite y tres dependencias. Eso es todo lo que hay detrás de marketyour.games, un producto web comercial con cuentas de usuario, panel de búsqueda para creadores de contenido, carpetas de organización, pagos vía Stripe y correos transaccionales con Postmark.

Lo llamativo no es lo que hace, sino cómo está construido. El autor lo describe como un stack moderno en todo menos en la forma en que se sirve: un programa en C que responde a variables de entorno CGI, servido por httpd de OpenBSD. La interfaz no requiere JavaScript y sigue el principio de mejora progresiva.

Para un founder acostumbrado a encadenar frameworks, gestores de paquetes y contenedores, la pregunta obvia es por qué alguien elegiría esto en 2026. La respuesta tiene menos que ver con nostalgia y más con costos operativos.

¿Qué es el stack BCHS y qué incluye exactamente?

El autor lo resume en cuatro piezas: OpenBSD, C, httpd y SQLite. La sigla se conoce como BCHS y no es nueva, pero su aplicación a un producto comercial en producción sí es poco común.

Las decisiones concretas que describe son estas:

• No hay framework. El programa lee variables de entorno CGI y responde.
• No hay lenguaje de plantillas. El C genera el HTML directamente.
• No hay servidor de base de datos separado. La aplicación abre el archivo SQLite a través de su API en C.
• No hay contenedor. Se compila un binario estáticamente enlazado y se deja en una carpeta.

Sobre las dependencias, el autor aclara que solo dos son dependencias de compilación reales: libcurl y libsodium, ambas incluidas en el propio proyecto. El resultado, según su relato, es un build limpio que tarda unos segundos y recompilaciones completas en menos de medio segundo.

En lugar de servir activos estáticos por la vía tradicional, todo el tráfico pasa por el binario CGI: cada activo se compila dentro del ejecutable y se sirve desde memoria. Y en el plano de seguridad, el autor apoya en herramientas propias de OpenBSD como pledge y unveil, además de que httpd sirve desde un chroot por defecto, de modo que el binario corre aislado en su propia esquina del sistema de archivos.

¿Por qué CGI vuelve a tener sentido en 2026?

El argumento central del artículo es que las razones por las que abandonamos CGI a comienzos de los 2000 ya no se sostienen. El autor lo plantea sin ambigüedad: su declive estaba justificado en 2004, pero no en 2026.

Hay tres puntos que sostienen esa tesis:

La especificación no cambió. La versión 1.1 de CGI se publicó en 2004 y no se movió desde entonces. No hay API que memorizar: la interfaz completa son conceptos fundamentales de HTTP. Si entiendes HTTP, entiendes CGI.

Un solo servidor web. Un stack moderno típico pone nginx adelante y hace proxy inverso a un servidor de aplicación escrito en otro lenguaje. El autor lo describe como algo extraño: dos servidores web, y uno de ellos además cargando con la lógica de negocio. Con CGI, un único servidor web llama directamente a tu lógica.

El debugging se simplifica. La aplicación es un programa común que puedes ejecutar desde una shell: le pasas una petición por pipe, observas stderr, la recorres con gdb.

El autor también traza un paralelo interesante: CGI se parece a la arquitectura serverless, donde un supervisor invoca tu código por request, le entrega un paquete de variables de entorno y recoge el resultado. La diferencia, dice, es que CGI es serverless sin proveedor y sin facturas sorpresa.

Sobre el costo de crear un proceso por request, su postura es que el fork no es ni de lejos tan caro como lo era entonces, porque los kernels modernos lo optimizan. Y si algún día se volviera un problema, señala que FastCGI es una actualización lo bastante simple.

Menos dependencias, menos superficie de ataque

El autor conecta su elección con un contexto que cualquier equipo técnico debería mirar con atención: el estado de las cadenas de suministro de software.

Su argumento es que un grafo de dependencias se infla rápido: una o dos dependencias directas pueden arrastrar cientos de indirectas, cada una mantenida por alguien que no conoces. Frente a eso, su cadena se reduce a un compilador de C y tres librerías.

Los datos recientes le dan peso a esa preocupación. BleepingComputer reportó que el malware autopropagante ChainDrop comprometió más de 1.300 paquetes del registro npm, con un total combinado de 2.000 millones de descargas mensuales. En un caso relacionado, Developer Tech documentó que el SDK de npm de Tensorlake, versión 0.5.144, fue comprometido con un gusano que roba credenciales, en un paquete con aproximadamente 12.000 descargas semanales y más de 1.000 estrellas en GitHub; la firma de seguridad Socket identificó la publicación maliciosa el 8 de octubre de 2026.

El patrón no es aislado. Hackread reportó que la campaña MALFEX usó al menos 12 paquetes de npm para distribuir un troyano de acceso remoto, con un operador activo desde agosto de 2023. Uno de esos paquetes siguió siendo malicioso e instalable durante 14 meses.

La conclusión del autor es directa: comprometer su cadena exigiría comprometer libcurl, un proyecto que vigila todo internet, no un paquete con once descargas semanales cuyo dueño se fue en 2019.

¿Qué significa esto para tu startup?

No se trata de reescribir tu producto en C. Se trata de auditar cuántas capas agregaste y si cada una se paga sola.

1. Cuenta tus dependencias indirectas, no solo las directas. Abre tu archivo de dependencias y mira el árbol completo. Si una librería que usas para una función trivial arrastra decenas de paquetes transitivos, ese es tu riesgo real. La pregunta útil no es "¿cuántas dependencias tengo?" sino "¿cuántos mantenedores desconocidos pueden ejecutar código en mi build?".

2. Evalúa SQLite para productos de carga moderada. El autor viene de usar Postgres por defecto y describe su carga operativa: un proceso que cuidar y releases frecuentes que actualizar. SQLite no tiene nada de eso: sin proceso, sin configuración, sin dependencias. Para un SaaS temprano, un producto de un solo tenant o una herramienta interna, esa diferencia puede ahorrarte horas de operación al mes. Si tu producto necesita escritura concurrente intensa o múltiples nodos, la conversación es otra.

3. Separa la lógica de negocio del servidor web. El punto más trasladable del artículo no es C ni CGI, sino la arquitectura: un servidor web que llama a tu lógica, en lugar de dos servidores donde uno hace de proxy y de aplicación a la vez. Si tu stack actual tiene capas que solo existen para conectar otras capas, vale la pena preguntarse qué se gana con cada una.

4. Mide el costo real de tu tooling. El autor usa Vim sin plugins: sin autocompletado, sin formateadores, sin asistentes. Su argumento es que los stacks complejos exigen herramientas complejas, mientras que un stack simple se lee abriendo un archivo. No es una recomendación universal, pero sí un recordatorio de que cada capa de abstracción cobra en configuración, en tiempo de onboarding y en dependencias.

Conclusión

El artículo no propone que todos volvamos a 1994. Propone algo más incómodo: que revisemos si las razones por las que descartamos ciertas tecnologías siguen siendo válidas. El autor señala que CGI es viejo pero no está olvidado, y que su producto comercial corre sobre un modelo de servicio estandarizado en 2004 con menos piezas móviles que cualquier cosa que haya lanzado antes.

Para un founder, el valor no está en copiar el stack, sino en la pregunta que habilita: ¿cuántas de las capas de tu infraestructura existen porque las necesitas y cuántas porque son el default?

Fuentes

• A Modern Web App in C (fuente original)
• Latest Supply Chain Attack news - BleepingComputer
• ChainDrop supply chain attack injects credential-stealing worm into Tensorlake SDK - Developer Tech
• MALFEX npm Attack Spreads Windows RAT, Steals Discord and Browser Data - Hackread