Welcome to part one! This is the start of a series where I’ll be posting about my webdev and HTML nightmares. I hope you enjoy the read as much as I hate User Interfaces! Consider this a shared space for learning—I’m sharing what I’ve learned so far, and I’d love to hear your thoughts or better solutions in the comments. To kick things off, let’s talk about how this whole mess started. As a solo developer, you want to spend 99% of your time actually building the things you love. So when it’s time to share builds with early playtesters, I naturally take the path of least resistance... a pinned link in a Discord channel and a shared Google Drive folder. And for a while, it works. Until it suddenly doesn't. The Problem: The "Easy way" Trap Privately, with a small group of alpha testers, Discord is great. You can pin messages, create specific channels, and guide people directly. But as soon as you want to go public, Discord becomes a nightmare for onboarding new users: The "Tutorial" Requirement: If a new user needs a 5-minute guide just to navigate your Discord server to find the launcher or the latest release, you’ve already lost them. Zero Discoverability: Discord is great for community and chat, but terrible as a public storefront or documentation hub. Searching for news, filtering updates, or finding launcher links creates massive friction. Lack of Professionalism: To offer real support, showcase features, and look trustworthy to a public audience, you need a single source of truth—not a maze of text channels lost to the void. I didn't have time to manage an overly complex custom web setup or pay high monthly SaaS fees, but I needed a clean, low-maintenance way to go public. Yes, I spent no more than thirty seconds drawing this on my Bamboo tablet: Why Google? (And the Launcher Evolution) Before even thinking about the website, I had to solve the distribution problem for my launcher. I experimented with several download pipeline prototypes: Git Repos / Diversion (for games) / Source control in general: Great for code, terrible for end-users who just want to click and play. OneDrive & Self-Hosted SSH Servers: Too clunky, overly complex to maintain, and lacked proper download resume functionality or hash diffing without building a massive backend infrastructure. Eventually, Google Drive API became the hero. It gave me reliable storage, easy access control, and seamless integration for the launcher's update system. Since my distribution ecosystem was already anchored in Google, it made sense to look at Google Sites when I needed a public web front. While researching frontend tools and wrestling with my nemesis (XAML and HTML), I kept comparing third-party web builders to Google Sites. Most SaaS builders cost $15–$30/month. As a solo dev on a budget who just wanted a fast, zero-cost, low-maintenance portal—Google Sites won. However... "Free and simple" comes with a cost. Fighting the Google Sites Iframe Sandbox Google Sites is great for basic drag-and-drop pages, but as soon as you try to build something custom with embedded HTML, you run straight into a wall of iframe security restrictions. Google Sites is amazingly smooth if you stick 100% to their default drag-and-drop elements. But as developers, we always want that extra layer of control—a custom button style, an embedded widget, or a tailored UI element. Naturally, I opened the "Embed HTML" block. And that's when I hit the iframe wall. Because Google Sites isolates all custom HTML inside a sandboxed <iframe>, the browser treats your embedded code as an untrusted external frame. The Goal: I wanted custom HTML buttons that could navigate the main website seamlessly without reloading or opening new tabs. The Reality Check: Browsers block target="_parent" or target="_top" calls inside sandboxed Google Sites iframes due to security policies. Standard navigation scripts just quietly fail or get blocked. The Workaround (External vs. Internal) Since I couldn't bypass browser security rules, I had to divide my navigation strategy into two distinct flows: For External Actions (Gumroad, Discord, Support Email): I kept these as custom HTML/CSS buttons. Forced them to explicitly open in a new tab using target="_blank". This respected iframe security while still giving me full control over button styling, hover effects, and layout. For Internal Site Navigation: I abandoned HTML embeds for internal links. Instead, I placed native Google Sites navigation components directly underneath the Hero Banners. By leveraging Google Sites' built-in UI components for internal pages, navigation stayed smooth, instant, and 100% functional without breaking frame security. What's Next? With the structure finalized and a solid, free foundation using Google Sites, I had solved my immediate friction problem. The transition from the chaotic, pinned Discord channels to a clean portal was a massive relief. However, as any developer knows, launching is just the beginning. In the next post, I’ll be tackling something I deliberately delayed: The Mobile Nightmare: How do you make a Google Site (where 90% of the content is custom embedded HTML) look decent on small devices? AI Compatibility & Discovery: Forget standard SEO. How do you design your site structure and sitemaps so that LLM-based search agents and AI crawlers can actually find and categorize your content, especially when using subdomains with third-party tools like Squarespace? We’ll explore sitemaps for robot navigation, AI optimization, and building an automatic menu from a crawler CLI in Part 2. Stay tuned! See it in action If you want to check out how the final setup turned out (and test the navigation buttons yourself), you can visit the live portal here: Live Site: kadmium.dev AI Summary Page: kadmium.dev/ai-summary (A little preview of what we'll talk about in Part 2!) If you have any advice, suggestions, research, or articles, feel free to drop a comment below or contact me at emil@kadmium.dev.