80/20 Engineering: How I Rebuilt My Site in a Weekend

Let me tell you a secret: I didn't rewrite my personal website in a weekend because I'm particularly fast at coding. I did it because I barely coded at all.

Instead, I spent most of my time doing what most developers avoid like the plague—preparing. Documenting. Writing things down. And when I finally opened up my editor and started working with OpenAI's Codex, the actual implementation flew by like a well-rehearsed magic trick.

This is a story about doing 80% of the work before writing a single line of code, and how that changed everything.

Why Rewrite the Site?

My site was running on Qwik v3. Solid tech, good vibes, but I wanted more flexibility—especially in routing. I made the switch to React Router in framework mode. A complete rebuild, not a refactor. New architecture, clean file structure, updated styling (hello Tailwind v4), and a blank slate.

But here's what surprised me: the actual coding took about 2–3 hours. Start to finish. And it worked on the first try.

So what happened in the other 5 hours?

The 80%: Prepping Codex Like a Consultant Preps a Pitch Deck

Most of the effort went into building a "mega prompt system"—not in a fancy UI, but right in my project folder. This is what I did before asking Codex to write even a single component:

• I downloaded the entire React Router documentation and saved it into a /guides directory.

• I did the same for Tailwind CSS v4, converting the most relevant pages into Markdown using Firecrawl.

• I wrote a PROMPT.md file containing a project overview:

  • "Legacy code lives at /, new code goes into /app."
  • "Only minimal UI, focus on business logic."
  • "Use Tailwind v4. Stick to framework mode in React Router."
  • And so on.

This wasn't fluff. This was operational context—the kind of detailed brief you'd give a new team member on day one. Codex wasn't just guessing what I wanted. It had documentation in the repo. It had exact rules in plain English. It had constraints.

When I finally typed:

"Read PROMPT.md. First, migrate all routes to the new app."

Codex responded like it had been waiting for this assignment its whole life.

Mega Prompts, Minimal Hallucinations

The results were uncanny. Codex stuck to the instructions. It didn't hallucinate. It didn't try to invent things. It respected the "don't focus on UI" directive. The server logic was migrated with precision. The route configuration looked like I'd written it myself—if I had the patience of a compiler.

This wasn't just about "prompt engineering." It was about grounding Codex in the real and current specs. Not a vague list of tasks. Not a wishlist of features. But structured input, clear examples, and local access to the actual docs it needed.

What Took Time? Not the Code

Once the foundation was laid, the work split into two distinct phases:

1. Codex mode – Fast, structured, repeatable execution. It worked through migration, logic, and even some layout scaffolding with near-perfect accuracy.
2. Design exploration mode – Slow, manual, and open-ended. This was the human part: picking a look, trying layouts, experimenting with components. Once I had a working visual style, Codex picked up again to propagate the design patterns.

The only real slowdown came from me not knowing what I wanted something to look like—not how it should work.

The Real Insight: Codex is Only as Good as Your Prep

This weekend reinforced a shift I've been noticing in my work:

Coding is becoming the easy part. Planning is the hard part—and the most important.

For small- to mid-sized projects, I now treat the implementation as a 20% task. The 80% is front-loaded: gathering the documentation, writing scoped tasks, building contextual prompts.

Codex thrives with this kind of structure. If you feed it ambiguity, it'll give you ambiguity. But if you build your environment with intent—docs, constraints, clear descriptions—it performs like a senior developer with perfect recall and no ego.

Going Forward: Treat AI Like a Teammate, Not a Genie

The takeaway is simple: treat your AI coding tools like collaborators. Give them the same materials you'd give a real engineer. Prep the context. Be specific. Be exhaustive.

Next time, for a bigger project, I'll go even further:

• One master plan doc to define the full project scope.
• Individual task specs per subsystem or component.
• A working set of markdown docs and example files as a local reference base.

Codex doesn't need magic words—it needs structure.

Want to build faster? Start by not building. Plan first. Then prompt like you mean it.

The Evolution of Design: A Visual Journey

Over time, my site has gone through several transformations—each one a reflection of new ideas, tools, and lessons learned. Here's a quick visual tour of how things evolved:

Version 1: The Starting Point

Version 2: A More Defined Voice

Version 2.1: Tweaks and Refinement

Version 3: The Qwik Era

Version 4: Focused Simplicity with Remix

Each version brought new insights into what makes a site effective—not just in aesthetics, but in clarity, usability, and maintainability. The design journey has mirrored the development one: deliberate, iterative, and always looking forward.