How a Scrabble Website Inspired Me to Rebuild Double Atari

A few weeks ago, I had dinner with my mom and a friend of hers. Her friend also happens to be the mom of my friend Jeff, who I had not talked to in over a year.

After dinner, I texted Jeff to see what he was up to.

Jeff is an engineer, and he told me he had built a website for Twin Cities Scrabble using Claude. He had never built a website before, which immediately made me curious. When I opened the site, I was surprised by how fast it felt. Just a clean, simple site that loaded almost instantly.

So naturally, I ran a Lighthouse scan. The scores were excellent. That was the moment I thought, “Okay, I need to try this myself.”

The idea started with Scrabble

What caught my attention was not just that Jeff had built a website. It was that the site felt so direct. It did what it needed to do without making the browser work too hard.

I asked him how he built it. He walked me through his process, and I started thinking about how I could use a similar approach for Double Atari. I did not want to simply make a fast site, though. I wanted to see if I could combine that lightweight build process with the things I care about professionally: SEO, AEO, GEO, content structure, analytics, and practical website strategy.

Starting with the site I already had

Double Atari already had a Squarespace site. It was useful, and it gave me a starting point for the brand, the services, and the overall direction. I also had my LinkedIn profile and personal website, which helped fill in the background: past work, experience, positioning, client history, and the kinds of projects I wanted to talk about.

The goal was not to throw everything away and start over. It was to take what already existed and make it sharper, faster, and more intentional.

I wanted the new site to feel simple, but not generic. Technical, but not cold. Optimized, but not written only for search engines.

The tools I used

The site was built with a pretty lightweight setup. Visual Studio Code handled the HTML, CSS, JavaScript, metadata, and schema. GitHub Desktop made it easier to manage changes without having to live in the command line. GitHub kept a clean version history. Cloudflare made hosting simple, fast, and free.

I also used AI tools throughout the process as a way to move faster through structure, copy drafts, code adjustments, schema markup, QA, and iteration.

I liked this process because it kept things simple. There was no theme to fight, no plugin stack, and no database. Just files, structure, content, and performance.

That does not mean this is the right setup for every website. I still like CMS platforms, and I work with them often. But for a focused consulting site, this approach made a lot of sense.

What I wanted to test

After seeing Jeff’s Scrabble site, I wanted to see if I could build something that was not only fast, but also strategically optimized.

Could I make a site that loaded quickly and still had thoughtful SEO? Could I make something lightweight that also worked for AI search, answer engines, and local discovery? Could I use AI as part of the process without ending up with something that looked or sounded generic?

That became the experiment.

I spent a lot of time thinking about page structure, internal links, headings, metadata, schema, image choices, and how the content should explain what Double Atari actually does. I also wanted the site to reflect my own background more clearly: SEO, GEO/AEO, website audits, CMS work, content strategy, analytics, and hands-on web development.

What surprised me

The biggest surprise was how fast the process moved once the structure was in place.

AI was helpful, but not in a “press a button and get a website” kind of way. It was more like having a very fast collaborator. I could ask for options, test layouts, revise copy, fix code, add schema, check page structure, and keep iterating.

But I still had to make the decisions.

That part feels important. AI can speed up the work, but it does not replace taste, experience, or strategy. If anything, it makes those things more important because you can generate a lot of mediocre options very quickly.

The real value came from knowing what to keep, what to cut, and what needed to feel more like me.

Core Web Vitals for an AI-built website in 2026

The target keyword for this post is practical rather than fancy: building a fast SEO-friendly website with AI. Fast still has a real meaning. For Core Web Vitals, I use the familiar Google thresholds as the floor: Largest Contentful Paint at or under 2.5 seconds, Interaction to Next Paint at or under 200 milliseconds, and Cumulative Layout Shift at or under 0.1. If a page misses those numbers, I want to know why before I worry about another design flourish.

AI can help generate code quickly, but it can also generate too much of it. The fastest AI-assisted builds are usually the ones where you ask for restraint: semantic HTML, one stylesheet, minimal JavaScript, optimized images, system-aware font loading, and no heavy animation library unless the interaction truly needs it. A static page with clean markup is often a better SEO foundation than a complex app pretending to be a brochure site.

My practical checklist is simple. Set image dimensions so the layout does not jump. Use compressed WebP or AVIF where possible. Keep scripts deferred. Avoid third-party widgets unless they are worth the performance cost. Test the homepage and your most important service pages in Lighthouse and PageSpeed Insights, but also open the site on a real phone. If it feels instant, the numbers usually make sense.

AI tools worth using vs skipping

AI is useful when it speeds up structure, not when it replaces judgment. I like using it to draft page outlines, generate schema candidates, refactor repetitive HTML, create metadata variants, check internal link opportunities, and write test cases for QA. Those jobs are bounded, reviewable, and easy to improve with a human pass.

I am more cautious with AI-generated design systems, large blocks of final copy, and entire site builds created from one prompt. That is where sameness creeps in. The tool will give you plausible sections, but it will not know which trade-offs fit the brand, which proof points are actually true, or which page should exist in the first place. For marketers, the best workflow is to use AI as a fast production assistant while keeping positioning, hierarchy, and quality control in human hands.

The tools worth using are the ones that keep you closer to the work: code assistants for small edits, language models for outline options, Lighthouse for performance checks, Search Console for real search behavior, and schema validators for structured data. The tools worth skipping are anything that hides the HTML, bloats the page, or makes it harder to maintain after launch.

Why I cared about speed

Speed was one of the main reasons I wanted to try this. Jeff’s site felt so immediate, and that made an impression.

A fast site just feels better. It removes friction. It gives the content a better chance to do its job. It also makes technical SEO easier because there is less unnecessary stuff in the way.

I did not want a site that only looked good in a screenshot. I wanted it to feel good when someone actually used it.

What I ended up with

The new Double Atari site is still a work in progress, but it feels much closer to what I wanted.

It is faster. It is cleaner. It is easier to maintain. It explains the work more clearly. It also gives me a better foundation for writing, testing, measuring, and continuing to improve the site over time.

The whole thing started because I texted a friend after dinner and asked what he was up to.

That is probably my favorite part of the story.

Sometimes a useful idea does not come from a conference, a webinar, or a trend report. Sometimes it comes from a Scrabble website built by a friend who had never built a website before.

A few practical questions

What tools did you use to build the Double Atari website?

I used Visual Studio Code, GitHub Desktop, GitHub, Cloudflare hosting, and AI tools to help with code, content structure, SEO elements, and iteration.

Why did you choose a static website instead of a CMS?

For this version of the site, I wanted something lightweight, fast, and easy to maintain. A static site made sense because the content was focused and did not require a complex publishing workflow.

Can AI help build a good website?

Yes, but it works best when there is a clear strategy behind it. AI can help with code, structure, copy, schema, and QA, but the final decisions still need human judgment.

Is this approach right for every website?

No. Some websites need a CMS, ecommerce features, user accounts, complex integrations, or a larger content workflow. This approach works best for focused sites where speed, clarity, and maintainability matter most.

What Core Web Vitals should an AI-built website hit?

Use the standard good thresholds as the floor: LCP at or under 2.5 seconds, INP at or under 200 milliseconds, and CLS at or under 0.1. A lightweight AI-assisted build should usually do better than that because it can avoid heavy themes, plugin bloat, and unnecessary scripts.

What AI website tools are worth using?

Use AI tools for bounded, reviewable jobs: page outlines, schema drafts, metadata variants, HTML refactoring, internal link ideas, and QA checklists. Pair those with Lighthouse, PageSpeed Insights, Search Console, and schema validators. The useful tools speed up production without hiding the underlying structure.

What AI website tools should marketers skip?

Skip tools that create bloated pages, lock you into unclear markup, or produce generic copy you cannot defend. A website still needs positioning, taste, accessibility, performance, and measurement. If an AI tool makes those harder to inspect or maintain, it is creating technical debt instead of speed.