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.
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.