I. The Optimization Instinct

I am, at my core, an engineer. Not just by degree—Mechatronics and Robotics—but by instinct. Throughout my career, whether I was managing supply chains, handling financial risk protocols, or writing algorithms, I have always been the person in the room looking for the inefficiency. I look for the red tape, the manual repetition, and the "black boxes" that no one understands.

And then I fix them.

We are living through an AI hype cycle that is deafening. CEOs are selling AGI fantasies while engineers are struggling to integrate basic APIs reliably. I decided to tackle AI the same way I tackled robotics: by taking it apart.

I built HugoPalma.work not just as a portfolio, but as a living laboratory. I wanted a space to journal my transition from "Traditional Engineering" to "AI Infrastructure Strategy," but I refused to do it the easy way. I didn't want a Wix site or a generic WordPress template.

The Cloudflare Audit (Dec 18, 2024)

When I deployed this server, the AI suggested I use "Rocket Loader" scripts and complex cloud caching layers to improve performance. A non-technical user would have accepted this "optimization."

I rejected it. Because I understand the stack from the metal up, I knew that for a 29MB Go binary, these scripts were "Snake Oil"—adding bloat rather than speed. This site runs on raw efficiency, not marketing plugins.

II. Why I Rejected React

In a world of 500MB node_modules folders and complex Docker-Kubernetes orchestrations, I chose to go the other way. When I scoped the architecture for HugoPalma.work, I had one non-negotiable constraint: Efficiency.

The Stack Comparison

I included a full custom CMS in that 29MB binary. It has a Monaco Editor (the same engine VS Code uses), a secure OIDC login system, and a WebSocket-based terminal.

If I had used a standard framework, I would be managing dependency updates, fighting hydration errors, and paying for cloud compute I don't need.

By understanding the stack from the metal up, I stripped away the bloat. I don't need a "Build Step" in production. I don't need a complex CI/CD pipeline. I compile it, I upload it, and it runs.

III. How Light Can It Get?

You might be wondering: "Is this really that unusual? Aren't all modern websites built this way?" The answer is no. Let me show you what "normal" looks like.

The Anatomy of My 29MB Binary

Alternative Approaches Ranked by Size

1. Static HTML + CDN (~100KB) ⚡

Pros: Absolutely minimal, free hosting, instant global CDN

Cons: No dynamic content, no database, no admin panel

Sacrifice: Everything that makes the site useful

2. LAMP Stack (~300MB+) ●

Apache (55MB) + PHP (15MB) + MySQL (200MB+)

Verdict: 10x larger footprint for the same functionality

3. Node.js + Express (~250MB+) ■

Node runtime (50MB) + node_modules (200MB)

Load time: Your Go binary: <1ms | Node.js: ~500ms

4. Next.js / React (~400MB+) ◉

Server: 400MB | Client bundle: ~300KB

Result: 13x larger, 3-4x slower page loads

Resource Usage Comparison

IV. Is This Common? No. Should It Be? Maybe.

Why It's Rare

• Developer Familiarity: Most devs know JavaScript/Python, not Go
• Vendor Ecosystem: Vercel/Netlify push their platforms (Next.js/Gatsby)
• Framework Hype: "Modern" = React/Vue, not vanilla
• VC Money: Free tiers subsidize bloat (Vercel, Supabase, etc.)

Why It Works for Me

• Low traffic: Personal portfolio, not scaling to millions
• Simple needs: CMS + auth + database, no real-time features
• Systems background: I understand the stack from metal up
• Control preference: Single binary > orchestrating 10 services

When to Switch

V. Proof of Work

I have proven time and again—from purchasing departments to trading desks—that I am the person who can spot a flaw in a process and streamline it using technology. Recently, that technology has been AI.

But AI isn't magic. It's just another layer of automation, similar to the JIT (Just-In-Time) inventory systems I built for e-commerce. It requires architecture, constraints, and rigorous auditing.

This website is my proof of work. It is where I show, not just tell, how to build self-sustaining, efficient systems in an era of digital bloat.

Final Verdict: Already Winning

The 29MB binary is:

Most "modern" web apps come with:

Could it be lighter? Yes, down to 8MB with UPX compression, or 0 bytes with static HTML.
Should it be? No. The admin panel (Monaco editor, terminal, database management) is worth every one of those 29 megabytes.

This is as light as reasonable gets while maintaining full CMS functionality.