How I wrote 200 pages before writing a single line of code: the story of URG

Between January and February 2026 I started the most ambitious project I had ever attempted: a complete online store for URG Technology↗, a Bogotá company with more than twenty years in computer repair. For close to two months I barely touched code. I wrote a document. When I closed it, on April 27, it ran to about 195 pages.

A lot of people ask me if that was not a waste of time. This is the story of why I did it, what was inside it, which tools I tried, and where that plan got things wrong once the store actually came to life.

The problem that had to be solved

URG used to be called INCOLSERVICE. It was a repair shop across from Unilago that fixed computers of every brand and had a mostly invisible specialty: taking in machines other people had written off as a total loss and bringing them back to life. With the rebrand came a new name, a new logo, and a new identity, but the same services.

My idea was to sell those refurbished computers online. It sounded simple. The real challenge was different: getting someone to buy a used computer, sight unseen, from a company they did not know. That is not solved with a pretty page. It is solved with trust, and trust has a lot of moving parts.

First, a four-page canvas

Before the big document, I wrote a short proposal I called INCOLSERVICE 2.0. It was a business canvas, not a design: a four-page site (home, buy a PC, sell your PC, and repair service) and the offer organized by customer type: gamers, home users, creators, and business owners.

That early text already had ideas that survived to the end. WhatsApp on the right, where the thumb reaches without effort. A real map of the shop. And a line that looks minor and is not: "we are on the second floor." For someone afraid of getting scammed, knowing exactly which stairs to climb changes everything. It also left three questions for every change: does it build excitement? does it build trust? does it drive sales?

What was inside nearly two hundred pages

The document was called URG Technology Tienda Digital, versión 1.1. It was not a manual for later. It was the complete instruction set for what to build, written so an AI or an outside team could stand up the store without guessing anything. I organized it like this:

1. 1Identity and pricing logic: the brand purple, the crossed-out price, and the discount percentage.
2. 2The home page, block by block, and every tab of the store.
3. 3The three product-page formats, one for each stage of the purchase.
4. 4The payment form and the system for naming orders.
5. 5The admin panel, split into four blocks.
6. 6Twenty-five rules for preventing errors.

That last part is the one I value most. Every rule answered an uncomfortable question: what happens if the connection drops? what if an ad blocker stops the payment gateway? what if two people pay for the same unit at once? what if someone tries to guess the admin panel's address?

Why write so much before building

Because in a store, the expensive mistakes are almost never about design. They are about logic: a miscalculated VAT, a unit sold twice, an email that never goes out. An ugly color gets fixed quickly. A double sale ends in a refund, an apology, and a customer who no longer trusts you.

Writing those cases down first forced me to think them through while they were still cheap to fix. On paper, a mistake gets erased with one stroke. In code, sometimes you have to tear down what was already built on top of it.

The document also worked as memory and as a contract. When something broke, I went back to it to check what had actually been promised and what had changed. It never depended on what I remembered or on what the AI assumed.

Three tools and a first night

With the document ready, I had to choose what to build with. First I tried Google Antigravity, a coding environment with AI agents, and it did not work out for URG. Then I went to Figma: the result looked good, but the cost did not add up for a project running on my own resources, without a team.

Then came Claude, Anthropic's AI assistant, and on the very first night I knew it was the right tool. It was not magic. It could take in an enormous document, understand the business rules, turn them into working code, and come back to that code when something broke.

Four months and 293 tasks

I worked alone for about four months, many sleepless nights, with the document on one side and the AI on the other. Every task got requested, tested, and logged, and when the result did not convince me, I asked for it again with more precision. In the end there were 293 tasks, from v1.0 in April to v24.18.26 in June.

Many were tiny, and that was exactly their value. The payment logos in the footer went through seven iterations just to get every single one's size right, because the Mercado Pago logo (a Latin American payment gateway) carries more white space than the Visa one, and without compensating for that the row looks messy.

Where the plan got it wrong

Here comes the honest part. The document did not get everything right, and some of the best decisions in the project consisted of going against it:

• The deal-of-the-day button. In V1.1 it jumped straight to payment. In the real store it goes to the product page first: whoever sees photos, specs, and warranty terms before paying buys with the right expectations, and that cuts down returns.
• The photo of a sold unit. The document called for turning it black and white. We tried it and reverted it, because the real photo sells more even after the unit is gone.
• The store that depended on a browser tab. The first version needed an administrator with the panel open to process payment confirmations. By v24.18.25, everything critical had moved to the server.
• The watchdog that was not in the plan. Centinela, the module that flags silent failures, did not exist in the original document. It was born in v24.18.24, after the real problems showed up.

That is why a second version of the document exists. V2.0, from June 19, 2026, has 98 pages and rewrites the first one with the store's real state, verified in the code. Read together, they show something you almost never get to see: the distance between the plan and reality, and how it was closed.

Where URG stands today

URG is built to 95%, live on its own domain but not launched. I have no sales figures to share because it has not sold anything yet, and I would rather say it plainly. What was missing was not code: it was professional product photography, a marketing plan, ads, and active social media. That lesson deserves its own article: a website without marketing does not sell.

While the launch is pending, the public storefront can be browsed at damorus.space. It is barely a quarter of the whole system: the other 75% is the private admin panel, and for security reasons it is not shown openly.

What I would do the same way tomorrow

If I started a store from scratch today, I would go back to writing before building. Not two hundred pages for every case: the size of the document depends on the size of the risk. But I would keep these three things:

1. 1Who is buying, what they fear, and what convinces them. Before designing a single screen.
2. 2The rules against expensive mistakes. Payments, inventory, taxes, and emails, written as concrete cases.
3. 3A second document with reality. Nothing is taken as done until it is verified in the code.