By Adam Hassan • May 11, 2026 • 7 min read
SiteSpin is a website builder that works through conversation and is designed for mobile. Instead of handing you a template and a tray of components, it asks a few questions and then builds the site for you. It runs on the Claude Agent SDK, and the sites it produces are static, dependency-light, and score 100 on mobile Lighthouse.
Read on for the thinking behind it, and for how those sites compare to the alternatives.
Most site builders today claim to simplify website creation for non-technical users, but the truth is that users need to make a number of design and structural decisions, usually by choosing a template and arranging components themselves. This approach is inherently limited and can be frustrating, as it demands both time and an understanding of what makes a website effective. The result is often a generic site that lacks distinction or real utility for the user.
The main issue is that current website builders expect users to do most of the work. This is the traditional way, and it hasn’t changed much. Even AI tools like Claude Code still need you to know what makes a good website, what accessibility and SEO mean, and how to give the right prompts. Instead of making things easier, these tools put the responsibility back on the user.
My own process for building a new website often involves Claude Code and a set of well-structured sites to reference. It works, but it still relies on someone who understands what makes a good website and how to guide the process. For most people the need is simple: a strong web presence, whether for business, discoverability, or credibility. The path to get there is unnecessarily complex.
If Claude Code can scaffold and generate a solid website with clear guidance, why can’t that be made accessible to everyone, regardless of technical background or design expertise?
SiteSpin is an attempt at that. The philosophy is to reverse the current mentality: instead of making the user responsible for every aspect of setup, the product takes on the heavy lifting. It asks a few questions, makes a lot of assumptions on the user’s behalf, and aims to deliver a well-architected site with minimal code, real content, sound structure, good accessibility, and perfect Lighthouse scores.
The Claude Agent SDK exposes the agentic loop that powers Claude Code as something you can program against. Instead of reaching the model through a chat window or a terminal, you can place it inside a workflow where it uses tools, reads and writes files, runs commands, manages its own context, and works through a task step by step.
For website generation, that opens up something new. A template forces every decision up front and then freezes it. An agent can produce a first draft, look at the result, change the structure, rewrite the copy, adjust the layout, and keep going until the site clears a defined quality bar.
The bar is the interesting part. If you can describe what good looks like precisely enough, the model can build toward it and then check its own work against it. That is the whole difference. The user isn’t being handed a set of decisions to make, they’re being handed a result to react to.
It shows up in small places. You send in your photos and never get asked where they should go, because working out which image belongs at the top of the page is exactly the kind of judgement most people came here to avoid making.
It also changes what onboarding feels like. The user talks about their business, who they serve, the tone they want, and what the site is for. Building a website starts to feel less like picking a template and more like briefing someone who already knows how sites should be put together.
The client is an iOS app. I chose mobile deliberately, because nearly every other builder assumes you are sitting at a laptop, and many of the people who most need a website never are.
Generation runs as a queued background job rather than inside a request. Building a site takes minutes, not milliseconds, so the work happens out of band and the app follows along. The agent works in an isolated workspace with a deliberately small set of tools and no network access, so it can only touch what it has explicitly been given. The output is a compiled static site, published to a CDN.
Progress reporting comes out of the loop itself. The agent reports where it has got to as it works, and the app shows that directly. There is no separate system watching from the outside and guessing at what stage the build is in. The model is the source of truth for what is happening, which is a small detail that makes the waiting feel honest rather than decorative.
Editing follows the same path as generating, with one difference: the SDK can resume the earlier session, so the model still has the site in context and makes targeted changes instead of rebuilding from scratch. That is what makes conversational editing quick enough to be worth doing at all. You say the headline is too formal, and the headline changes.
Most small-business homepages do not need what hosted builders bundle in by default: JS frameworks, slideshow libraries, analytics SDKs, chat widgets, font loaders. What matters is five content sections, a couple of images, a contact link, and solid typography. The bytes on the wire should reflect that.
SiteSpin sites are compiled Astro projects. HTML is generated at build time, and Tailwind runs in the same step, emitting only the classes actually used. Nothing hydrates on the client, because everything compiles to static markup. A Lighthouse 100 is not an optimization goal here, it is the floor, and it holds because the agent is tightly restricted in what it is allowed to introduce in the first place.
The gap this opens up is not marginal.
| platform | perf | transfer | js | lcp | req |
|---|---|---|---|---|---|
| sitespin | 100 | 152 KB | 2 KB | 0.8 s | 6 |
| webflow | 64 | 1.6 MB | 157 KB | 5.9 s | 37 |
| wix | 68 | 2.4 MB | 1.3 MB | 6.6 s | 230 |
| wordpress | 58 | 4.5 MB | 844 KB | 16.1 s | 151 |
| squarespace | 50 | 2.7 MB | 1.3 MB | 17.8 s | 78 |
lighthouse performance score · mobile, median · higher is better
javascript shipped to the browser · median · lower is better
total transfer size · median · lower is better
largest contentful paint · mobile, median · lower is better
I have kept the functionality deliberately narrow so far. The interesting question isn’t how many features a builder has. It is whether someone with no design background ends up with a site they are genuinely willing to put their name on and send to a customer.
So the roadmap comes from watching that happen, or watching it fail to happen. I would rather add the things real users get stuck on than the things that look good on a feature list.
The other direction is simply the models. Every improvement to the underlying model, and to the agentic SDK around it, makes generation faster and the output better without much changing on my side. That is an unusual position to build from, and a good one.
SiteSpin is available on the App Store.