Back to Home
March 12, 2026William Gomez

My website was a ghost town for 5 years. Here is how I’m engineering it to actually work.

My website was a ghost town for 5 years. Here is how I’m engineering it to actually work.

So, here is the main question: How do I convert random readers into people who actually want to work with me?

This is exactly what big agencies do daily for global clients. Having worked in some of them for years, I’ve seen first-hand that this is a massive learning curve. Believe me, world-class teams are trying to master this every day—balancing complex client requirements and technical constraints. It’s not just "blogging"; it's a discipline.

As a developer, I’ve realized that my brand needs a system, not just a layout. I’m treating this like a real product launch: defining requirements and building a way to measure everything. After all, "what you don't measure, you can't improve." (Somewhere, a Product Owner I once worked with is smiling right now, haha).

My Personal Product Requirements:

  1. Organic Discovery (Speed & SEO): To share knowledge, I need readers. To get readers, I need to solve their problems through Google search. This requires a perfect score in Speed (measured by PageSpeed Insights) and Visibility (monitored via Google Search Console).

  2. Operational Efficiency: Knowledge must flow. If posting is a manual pain (like editing raw code every time), I won’t do it.

  3. The "Follow-up" Loop (Retention): A reader "wanting more" is a lead. I need to bridge the gap between a technical post and my professional proof (GitHub, LinkedIn). Don't let your traffic evaporate.

  4. Measurability (The Feedback Loop): If I can't see how users behave, I'm flying blind. The site must have a clean Analytics setup to track the funnel from the first click to the final contact.

Once the requirements were clear, I hit a wall: a massive pile of overlapping questions. In engineering, nothing lives in a vacuum. I realized that solving for speed might break my SEO, and making it easy to update could kill my performance. It’s a chain reaction—every decision affects the next one.

Speed:

In the world of high-performance funnels, speed is the first filter. If your site is slow, you lose the lead before you even say hello. These are the results of PageSpeed:

Here is how I approached the architecture:

  • Static Export (Pre-computed Data): I chose this over SSR (Server-Side Rendering). The pages are already "built." Since my content doesn't need to change based on who is viewing it, I can pre-render everything. When you visit, there’s no server thinking—just instant data delivery. When you visit, there’s no server thinking—just instant data delivery.

    What options did I have?

    Strategy

    Performance (TTFB)

    SEO Friendliness

    Infrastructure Cost

    Client-Side (CSR)

    Slow. The browser has to download and execute JS before showing content.

    Poor. Search engine crawlers often struggle to index the page correctly.

    Low. You only host static assets.

    Server-Side (SSR)

    Variable. Depends on the server's response time for every request.

    Excellent. The server sends fully rendered HTML.

    High. Requires a server running 24/7 to handle requests.

    Static Export (SSG)

    Instant. Files are pre-rendered and served immediately.

    Perfect. Clean, pre-rendered HTML is ready for any crawler.

    Lowest ($0). Can be hosted on a global CDN for free.

  • Why I skipped Website Builders and CMS Monoliths? It’s tempting to use SaaS builders (like Wix or Squarespace) or monolithic CMS platforms (like WordPress), but they come with a hidden cost: the lack of control. These "black boxes" are built to be everything for everyone, which inevitably leads to code bloat and unoptimized rendering paths that kill your PageSpeed score.

    What options did I have?

    Platform Type

    Setup Speed

    Performance

    SEO Control

    Maintenance

    SaaS (Wix, Squarespace)

    Instant. Drag and drop.

    Low. Heavy "black box" code.

    Limited. You follow their rules.

    None. They handle everything.

    Monolith (WordPress)

    Fast. Thousands of themes.

    Medium. Depends on plugins.

    High. But requires heavy tuning.

    High. Updates, security, bugs.

    Custom (Next.js + Static)

    Slow. You build the engine.

    Perfect. Zero "ghost scripts."

    Total. Full control of the DOM.

    Minimal. No server to maintain.

  • Why I went with Firebase? While Vercel and Netlify are great for Developer Experience, I chose Firebase for its ecosystem depth. As a Google Cloud expert, I’m not just hosting a blog; I’m building a foundation. Firebase is my entry point to the entire GCP suite—meaning I can easily scale this project to include Vertex AI bots or Cloud Functions whenever I want. It offers a $0 cost-to-performance ratio with an infinite ceiling for future AI and data integrations.

    What options did I have?

    Provider

    Why people love it

    The "Catch"

    Best for...

    Vercel

    Everything is automatic and "just works" with Next.js.

    Can get expensive very fast if you have a lot of traffic.

    Developers who want Zero Friction.

    Netlify

    Great tools for forms, logins, and simple backend tasks.

    Their free tier has stricter bandwidth limits.

    Static sites with simple needs.

    Firebase

    Uses Google’s massive global network (the fastest backbone).

    A bit more "manual" to set up than Vercel.

    High Performance & Future Scaling.

SEO & Organic Reach:

If speed is the engine, SEO is the fuel. You can have the fastest website in the world, but if nobody finds it, you are just shouting into a void. For me, organic reach isn't just about keywords; it's about solving specific technical problems that people are already searching for. Pending results from this section will be update in the following image with the time (1-2 weeks):

  • Why I chose a Self-Hosted Blog? I’ve seen too many great technical articles disappear because a platform changed its monetization or its algorithm. By hosting my own content, I build Digital Equity. Every post I write is an asset that works for me 24/7, attracting the right people while I sleep. It’s not about "going viral"; it's about being the top answer when someone googles a specific technical challenge.

    What options did I have?

    Approach

    Reach Potential

    Effort

    Ownership

    Social Media Only

    High (but temporary).

    Very High (constant posting).

    None. You are at the mercy of algorithms.

    External Platforms (Medium, etc.)

    Medium. They have their own audience.

    Low. Just write and publish.

    Partial. They own the canonical link and the "look."

    Self-Hosted Blog

    Infinite. Compounds over time via Google.

    Medium. Requires setup and strategy.

    Total. You own the data, the brand, and the funnel.

  • Why did I chose a Headless CMS? Knowledge must flow. If publishing requires touching code every single time, the system fails. I chose a Headless CMS to decouple content from code: I get a world-class writing experience while my Next.js frontend handles the performance. This architecture ensures that my content remains an independent asset—I can redesign my entire website tomorrow without ever touching my articles. It’s the ultimate setup for scalability and operational ease.

    What options did I have?

    System

    Ease of Use

    Customization

    Maintenance

    Local Markdown Files

    High (for devs).

    High.

    High. Requires a code deploy for every typo.

    Full-Stack CMS

    Medium.

    Low (without theme hacking).

    High. You have to manage the whole stack.

    Headless CMS

    Excellent. Dedicated editor UI.

    Total. Content is served via API.

    Zero. The provider manages the database.

The "Follow-up" Loop: Converting Traffic into Trust:

Getting a reader to land on your site is a win, but letting them leave without a trace is a failure. I needed a way to bridge the gap between a reader solving a one-time problem and a potential partner recognizing my expertise.

  • Why I focused on Authority Proof? I do want to teach. In fact, I’m dedicated to explaining the core concepts of the modern stack, but I refuse to do it in a vacuum. My goal is to bridge the gap between "knowing the tool" and "owning the architecture."

    Concept Series with Context: When I explain a concept (like Rendering or Data Pipelines), I do it through the lens of real-world constraints. I’m not just teaching you Next.js; I’m teaching you how to think like a Lead when using it.

    Open-Source as a Textbook: Instead of a theoretical exam, I provide GitHub repositories. Every series I write is a "living lab" where you can see the concepts in action.

    The Professional Mentor: By sharing my experience alongside the theory, I build a Portfolio of Authority. The reader doesn't just learn a new skill; they learn to trust my judgment. You aren't just getting a tutorial; you are getting a roadmap from someone who has already paved the way.

    What options did I have?

    Approach

    Intent

    Value to Reader

    Your Role

    The "Resume" Blog

    Showcase achievements.

    Low. It feels like an ad.

    Job Seeker.

    Academic Tutorials

    Explain "How-to" basics.

    Medium. Good for beginners.

    General Tutor.

    The "Architect's Series" (The Choice)

    Mastering concepts through experience.

    Highest. Deep understanding + Context.

    Technical Mentor.

Measurability (The Feedback Loop):

If I can't see how users behave, I'm flying blind. However, for a high-performance site, I had a major constraint: I didn't want a heavy analytics script to kill the 100/100 PageSpeed score I worked so hard to achieve. I needed a way to track the funnel—from the first click on a Google result to the final conversion event (Calendly, Email, or LinkedIn)—without compromising privacy or speed.

  • Why I went with Umami? To be honest, I had never used Plausible or Umami before. Throughout my career, I’ve always relied on Google Analytics (and Firebase) because it’s what I know and use daily in large-scale projects. However, for this specific personal brand, I decided to step out of my comfort zone. After researching the trade-offs, I chose Umami because it aligns perfectly with my "Lean" philosophy and it has a free tier.
    Speed First: It’s 45x smaller than GA4, which keeps my PageSpeed at a perfect 100.
    Conversion Focus: It allows me to track exactly what I need: whether a reader from my "Architect's Series" ends up clicking on my Calendly, Email, or LinkedIn.
    Clean UX: Since it doesn't use cookies, I don't need to clutter my clean design with annoying cookie banners.

    What options did I have?

    Tool Type

    Performance Impact

    Privacy / GDPR

    Why it's used

    Google Analytics (GA4)

    Medium/High. Heavy scripts.

    Complex to anonymize.

    Industry standard for deep data.

    Plausible / Umami

    Minimal. Tiny scripts (<1KB).

    Native. No cookies required.

    Speed & Privacy.

The Result:

Building this wasn't just about having a blog. It was about creating a high-performance system that reflects how I work as a Developer: defining requirements, evaluating trade-offs, and choosing the best path for long-term scalability. Now, the engine is running, the metrics are clean, and the "Architect's Series" is ready to go.

Repository: https://github.com/williamegomezo/personal-website

See you in the next post—or better yet, let's connect on LinkedIn.