Emil Sjöstedt

Posted on Sep 18 AI-assisted

Zero-Budget Web Dev Part 2 — Mobile Breakpoints & Giving AI a Clean Entry Point

#webdev #ai #indiedev #showdev

Welcome back to Part 2.

In Part 1, I moved the Kadmium portal away from Discord chaos and onto a $0 Google Sites setup.

This part is about what happened afterwards: fixing the mobile layout, dealing with the limitations of embedded HTML, and giving AI crawlers a cleaner way to understand the site.

1. The Mobile Breakpoint Problem

Google Sites handles its native components reasonably well across different screen sizes. Custom HTML embeds are another story.

Embedded HTML runs inside sandboxed <iframe> elements, which means the embed has its own layout context. My original implementation relied too heavily on fixed pixel widths, so the desktop layout looked fine while smaller screens could end up with horizontal overflow.

Basically: desktop-first worked until someone opened it on a phone. 🤣

My bad.

The fix is fairly straightforward:

Use fluid widths such as width: 100%.
Apply sensible max-width values where necessary.
Use relative spacing such as rem instead of relying entirely on pixels.
Keep custom HTML components self-contained.
Let Google Sites handle the larger page layout through its native containers.

For embeds that contain their own HTML document, I also use an explicit viewport declaration:

<meta name="viewport" content="width=device-width, initial-scale=1.0">

The general rule I'm using now is: Google Sites handles the page layout. Custom HTML handles individual widgets. That keeps the two systems from fighting each other.

2. The More Interesting Problem: AI Crawlers

The mobile issue was annoying. The crawler problem was more interesting.

If you're trying to make a technical site discoverable through tools such as ChatGPT, Claude, Gemini or Perplexity, the crawler isn't necessarily interested in the page exactly the way a human visitor is.

A rendered website can contain:

Navigation elements
Styling & layout rules
JavaScript hydration
Embedded content & iframe boundaries
Duplicated markup & UI components

For a human, that's normal. For an AI system trying to extract technical information, it's additional context that may not be useful.

Google Sites also doesn't give me the same level of control over infrastructure that I would have on a conventional web stack. For example, I can't simply treat the site root like a server I fully control and configure everything around the crawler.

So instead of trying to make the crawler understand the entire rendered site, I decided to give it another option.

3. /ai-summary

I created kadmium.dev/ai-summary.

The idea is simple: Give AI agents a plain-text representation of the important parts of the site.

Rather than forcing a crawler to reconstruct the architecture from rendered pages,give it pieces of candy! The endpoint provides a structured Markdown index containing the information I actually want machines to discover.

The page includes things such as:

Project and product descriptions
Technical areas & module specs
Documentation routes & article links
Repository references
Metadata, versioning, and explicit boundaries around what is public and what isn't

It also follows the general direction of the emerging llms.txt pattern: provide machines with a deliberately simplified representation of a website instead of relying entirely on rendered HTML.

4. Why Explicit Boundaries Matter

One part I consider particularly useful is separating known public information from things that aren't actually exposed.

For example, the index can explicitly state that internal implementation details are not part of the public documentation. That's important because an AI system should not have to guess.

If the public documentation says:

This module exists and performs X.

That doesn't mean the model should invent the internal C++ implementation of X.

The /ai-summary document therefore acts more like an information boundary than just a sitemap. It tells an AI system:

Here is what you can verify from the public documentation.
Here is where to find it.
Here is what isn't being exposed.

That doesn't magically prevent hallucinations, but it gives the model a much cleaner source of truth to work from.

5. The Engineering Trade-off

I'm not trying to replace the actual website with a giant text dump. Humans still get the normal site.

The /ai-summary endpoint is simply another representation of the same information, optimized for machines that don't need the visual UI.

So the architecture is roughly:

                    ┌─────────────────┐
                    │   Kadmium.dev   │
                    │   Human UI      │
                    └────────┬────────┘
                             │
                    Public information
                             │
              ┌──────────────┴──────────────┐
              │                             │
        Human visitors                AI / crawlers
              │                             │
       Rendered website                 /ai-summary
              │                             │
        Visual context                 Plain Markdown

It's a small addition, but it means I don't have to rebuild the frontend just to make the underlying information easier for machines to consume.

6. An Honest Dev Note

I'm a C++ developer.

Given the choice, I'd rather spend 14 hours in Visual Studio working on Network Prediction Plugin rollbacks, SIMD vector math or engine architecture than debugging HTML padding. 😂

The portal exists for practical reasons:

Distributing builds
Publishing stress-test telemetry
Documenting the project
Handling B2B inquiries
Giving people a central place to find technical material

The actual engineering work is still where my attention goes.

If you want the raw architecture, the public C++ material is available here:

Public C++ Mirrors: KadmiumShowcase_UE
Technical Deep-Dives: Dev.to/kadmium
B2B & Audits: Kadmium Services

7. What I Learned

The main lesson from this was that a website doesn't necessarily need one representation.

The visual website is optimized for people.
A plain-text index can be optimized for machines.

And when the platform underneath you limits how much control you have over the rendered frontend, providing a separate machine-readable layer can be a surprisingly simple workaround.

The /ai-summary endpoint is still a work in progress, but that's the direction I'm taking for Kadmium.

If you're doing something similar with AI indexing, llms.txt, or machine-readable documentation, I'd be interested to hear how you're approaching it in the comments below!

AI Disclosure: The underlying codebase, architecture, and implementation are developed and tested by Kadmium in C++ / C#. AI tools were used to help refine parts of the documentation wording.

DEV Community