Cuaderno de espiral con una página llena de escritura a mano y un lapicero encima
Historias

Cómo escribí 200 páginas antes de escribir una línea de código: la historia de URG

Pasé cerca de dos meses escribiendo antes de programar la tienda de URG Technology. Te cuento qué llevaba ese documento, por qué lo escribí y en qué se equivocó cuando la tienda empezó a existir.

Alejandro Ujueta7 min de lectura

Entre enero y febrero de 2026 empecé el proyecto más ambicioso que había intentado: una tienda en línea completa para , una empresa bogotana con más de veinte años de servicio técnico. Durante cerca de dos meses casi no toqué código. Escribí un documento. Cuando lo cerré, el 27 de abril, tenía unas 195 páginas.

Mucha gente me pregunta si eso no fue perder el tiempo. Esta es la historia de por qué lo hice, qué había adentro, qué herramientas probé y en qué se equivocó ese plan cuando la tienda empezó a existir de verdad.

El problema que había que resolver

URG antes se llamaba INCOLSERVICE. Era un taller frente a Unilago que reparaba computadores de todas las marcas y tenía un oficio poco visible: recibir equipos que otros daban por pérdida total y devolverles la vida. Con la reestructuración llegaron un nombre nuevo, un logo nuevo y una identidad nueva, pero los mismos servicios.

Mi idea fue vender esos computadores reacondicionados por internet. Sonaba simple. El reto real era otro: lograr que alguien le comprara un computador usado, sin tocarlo, a una empresa que no conocía. Eso no se resuelve con una página bonita. Se resuelve con confianza, y la confianza tiene muchas piezas.

Primero, un lienzo de cuatro páginas

Antes del documento grande escribí una propuesta corta que llamé INCOLSERVICE 2.0. Era un lienzo de negocio, no un diseño: un sitio de cuatro páginas (inicio, comprar PC, vender tu PC y servicio técnico) y la oferta ordenada por tipo de cliente: gaming, hogar, creadores y empresarios.

Ese texto ya tenía ideas que sobrevivieron hasta el final. El WhatsApp a la derecha, donde el dedo llega sin esfuerzo. Un mapa real del local. Y una frase que parece menor y no lo es: "estamos ubicados en el segundo piso". Para quien teme una estafa, saber exactamente dónde subir la escalera lo cambia todo. También dejaba tres preguntas para cada cambio: ¿genera emoción?, ¿genera confianza?, ¿genera ventas?

Qué había en casi doscientas páginas

El documento se llamó URG Technology Tienda Digital, versión 1.1. No era un manual para después. Era la instrucción completa de qué construir, escrita para que una IA o un equipo externo pudiera levantar la tienda sin adivinar nada. Lo organicé así:

  1. 1Identidad y lógica de precios: el morado de marca, el precio tachado y el porcentaje de descuento.
  2. 2El home, bloque por bloque, y cada pestaña de la tienda.
  3. 3Las tres fichas de producto, una para cada momento de la compra.
  4. 4El formulario de pagos y el sistema para nombrar los pedidos.
  5. 5El panel de administración, dividido en cuatro bloques.
  6. 6Veinticinco reglas de prevención de errores.

Esa última parte es la que más valoro. Cada regla respondía una pregunta incómoda: ¿qué pasa si se cae la conexión?, ¿y si un bloqueador de anuncios frena la pasarela de pagos?, ¿y si dos personas pagan el mismo equipo al tiempo?, ¿y si alguien intenta adivinar la dirección del panel?

V1.1 · MAPA DEL NIVEL1 · ESCRIBIR2 · JUGARIVA!DOBLE VENTA!CORREO!25 REGLAS CONTRA ERRORESTIENDANIVEL SUPERADO
Primero se dibuja el mapa y se marcan las trampas. Después se corre el nivel.

Por qué escribir tanto antes de construir

Porque en una tienda los errores caros casi nunca son de diseño. Son de lógica: un IVA mal calculado, un equipo vendido dos veces, un correo que nunca sale. Un color feo se cambia rápido. Una venta doble termina en un reembolso, una disculpa y un cliente que desconfía.

Escribir esos casos primero me obligó a pensarlos cuando todavía eran baratos de corregir. En papel, un error se borra con un trazo. En código, a veces hay que desarmar lo que ya se construyó encima.

EN PAPELEN CÓDIGOMISMO ERROR · DOBLE VENTA1 TRAZODATOSPAGOSSTOCKFICHASPANELHOMEDESARMAR Y REHACER
El mismo error, dos precios: en papel se borra; en código hay que desarmar los pisos que ya están encima.

El documento también funcionó como memoria y como contrato. Cuando algo fallaba, volvía a él para ver qué se había prometido y qué había cambiado. No dependía de lo que yo recordara ni de lo que la IA supusiera.

Tres herramientas y una primera noche

Con el documento listo había que elegir con qué construir. Primero probé Google Antigravity, un entorno de programación con agentes de IA, y para URG no funcionó. Después fui a Figma: el resultado era bonito, pero el costo no cuadraba con un proyecto que avanzaba con recursos propios y sin equipo.

Luego llegó Claude, el asistente de IA de Anthropic, y la primera noche supe que era la herramienta. No fue magia. Podía recibir un documento enorme, entender las reglas del negocio, convertirlas en código que funcionaba y volver sobre ese código cuando algo se rompía.

Cuatro meses y 293 tareas

Trabajé solo durante unos cuatro meses, muchas noches sin dormir, con el documento a un lado y la IA al otro. Cada tarea se pedía, se probaba y se registraba, y cuando el resultado no convencía se volvía a pedir con más precisión. Al final fueron 293 tareas, desde la v1.0 de abril hasta la v24.18.26 de junio.

Muchas eran diminutas, y ahí estaba su valor. Los logos de pago del pie de página pasaron por siete iteraciones solo para ajustar el tamaño de cada uno, porque el de Mercado Pago trae más espacio en blanco que el de Visa y, sin compensarlo, la fila se ve desordenada.

Donde el plan se equivocó

Aquí viene la parte honesta. El documento no acertó en todo, y algunas de las mejores decisiones del proyecto consistieron en llevarle la contraria:

  • El botón de la oferta del día. En la V1.1 saltaba directo al pago. En la tienda real lleva primero a la ficha del producto: quien ve fotos, especificaciones y garantía antes de pagar compra con expectativas correctas, y eso reduce devoluciones.
  • La foto de lo vendido. El documento pedía volverla blanco y negro. Se probó y se revirtió, porque la imagen real vende más aunque el equipo ya no esté.
  • La tienda que dependía de una pestaña. La primera versión necesitaba un administrador con el panel abierto para procesar las confirmaciones de pago. En la v24.18.25 todo lo crítico se mudó al servidor.
  • El vigilante que no estaba en el plan. Centinela, el módulo que avisa cuando algo falla en silencio, no existía en el documento original. Nació en la v24.18.24, después de los problemas reales.
PLAN VS. REALIDADPLANREALv1.0v24.18.26CTA A FICHASERVIDORCENTINELA293 TAREAS DESPUÉS
La V1.1 corre como fantasma. La carrera real se desvía en tres curvas, tarda más y llega igual a la meta.

Por eso existe una segunda versión del documento. La V2.0, del 19 de junio de 2026, tiene 98 páginas y reescribe la primera con el estado real de la tienda, verificado en el código. Leídas juntas muestran algo que casi nunca se ve: la distancia entre el plan y la realidad, y cómo se recorrió.

Dónde está URG hoy

URG está construida al 95 %, en línea en su dominio pero sin lanzar. No tengo cifras de ventas que contar porque todavía no ha vendido, y prefiero decirlo así. Lo que faltó no fue código: fueron fotos profesionales de producto, un plan de marketing, pauta y redes activas. Esa lección merece su propio artículo: una web sin marketing no vende.

Mientras llega el lanzamiento, la vitrina pública se puede recorrer en damorus.space. Es apenas una cuarta parte del sistema: el otro 75 % es el panel privado, y por seguridad no se muestra abierto.

Lo que haría igual mañana

Si hoy empezara una tienda desde cero, volvería a escribir antes de construir. No doscientas páginas para todo el mundo: el tamaño del documento depende del tamaño del riesgo. Pero sí estas tres cosas:

  1. 1Quién compra, qué teme y qué lo convence. Antes de diseñar una sola pantalla.
  2. 2Las reglas contra los errores caros. Pagos, inventario, impuestos y correos, escritos como casos concretos.
  3. 3Un segundo documento con la realidad. Nada se da por hecho hasta verificarlo en el código.

¿Le sirve a alguien? Compártelo.

Tu proyecto con nosotros puede empezar hoy.

Cuéntanos qué quieres lograr, o eso que siempre quisiste que tu proyecto lograra, y te decimos cómo lo haríamos y cuánto cuesta. Si lo puedes imaginar, lo podemos hacer realidad.

o escríbenos por WhatsApp (+49 176 4454 2881) o a Alejandro@damorus.com