Anatomía de un encargo: la forja

Un taller de forja artesanal nos contactó a finales de 2024 con una petición sencilla en apariencia: un sitio que reflejara la disciplina del oficio y un canal de pedidos que el dueño pudiera operar él mismo desde el taller, sin pasar por una agencia cada vez que cambiara una pieza del catálogo.

El cliente es real; el nombre lo mantenemos anónimo a petición del estudio. Lo que sigue es la anatomía del encargo — qué se construyó, por qué, y cómo ha resistido sin intervención del equipo durante el último año.

Restricciones del encargo

Antes de la primera línea de código, calibramos cuatro restricciones que terminaron determinando la arquitectura entera:

1. El dueño opera el sitio desde el móvil, en pausas de quince minutos entre piezas. La superficie de administración tenía que caber en una pantalla.
2. El catálogo cambia despacio — entre tres y seis piezas nuevas al mes. Cualquier CMS pesado iba a ser desperdicio.
3. El presupuesto operativo era de menos de diez euros al mes, indefinidamente.
4. El sitio tenía que sobrevivir a periodos de varios meses sin nosotros tocándolo.

La arquitectura entregada

Una sola caja, una sola base de datos, sin servicios externos opcionales. El diagrama mental cabe en una línea: navegador → CDN estática → un VPS pequeño con Postgres y un binario.

-- esquema completo de la base de datos del taller
CREATE TABLE pieces (
  id          uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  slug        text UNIQUE NOT NULL,
  title       text NOT NULL,
  description text NOT NULL,
  price_cents integer NOT NULL CHECK (price_cents > 0),
  status      text NOT NULL CHECK (status IN ('draft','published','sold')),
  created_at  timestamptz NOT NULL DEFAULT now(),
  updated_at  timestamptz NOT NULL DEFAULT now()
);

CREATE INDEX pieces_status_created_idx ON pieces (status, created_at DESC);

Eso es todo. Once columnas, un índice, una restricción CHECK por estado. El catálogo del taller son piezas; las piezas tienen tres estados; el sitio renderiza las publicadas y reordena por fecha.

La parte de administración es un formulario <form> HTML clásico contra un endpoint en el mismo proceso, autenticado con una cookie firmada. Sin React en el panel. Sin SPA. El dueño puede editar el catálogo desde una conexión 3G en mitad del campo y el cambio aparece publicado en dos segundos.

Por qué Postgres para todo

Mucha gente nos preguntó por qué no usar un servicio especializado para imágenes, otro para búsqueda, otro para colas. La respuesta es la misma de siempre: cada servicio nuevo es un compromiso operativo que el cliente termina pagando — en dinero, en tiempo o en complejidad mental.

Postgres, en cambio, es una pieza que el dueño no tiene que mantener. La hosting la actualiza; nosotros la dejamos configurada con pg_dump semanal a un bucket frío; la recuperación se mide en minutos.

Lo que ha pasado en quince meses

El sitio lleva en producción quince meses. En ese periodo hemos tocado el código cuatro veces — tres de ellas por petición explícita del cliente (nuevos campos en el formulario de pedido), una por una migración menor de Postgres. Tiempo de respuesta medio en el dominio principal: por debajo de los 200 ms en p95. Coste mensual de operación: menos de doce euros, todo incluido.

Si quieres ver el patrón aplicado a otro sector, lee también Sistemas pequeños, duraderos — el manifiesto técnico desde el que partimos cada engagement.

El criterio que queda

No vendemos arquitecturas sofisticadas. Vendemos sistemas que el cliente puede operar y que nosotros podemos abandonar sin que el cliente lo note. Eso es el contrato.