This site is built with Chinaski
There's a version of this post that would be embarrassing to write: the one where the software that's supposed to make building websites easy turns out to be a nightmare to use on its own website. I'm glad that's not this post.
chinaski.net is a Chinaski site. The content is managed in Chinaski's admin, built into flat HTML by Chinaski's builder, and served as static files from nginx. The theme you're reading this on is a Template Toolkit theme living in the Chinaski database. Everything you've navigated to on this site went through the same pipeline described in the docs.
How it was built
Most of the build-out happened through the MCP server. I pointed Claude at the Chinaski MCP endpoint and worked through the site in conversation: create this page, add these blocks, set the metadata, wire up the nav. The AI drafted the copy for every page: 29 pages in English and Portuguese, across 57 content blocks.
That's not a workflow I expected to work as well as it did. The MCP tools are typed and explicit: create_page, update_block, trigger_build. The agent doesn't have to guess at structure. It creates a hero block, sets the heading and subheading, calls trigger_build, and the result is a live page. No web UI, no copy-paste, no fiddling with a rich text editor.
The content itself took maybe two hours of back-and-forth to get right. The agent would draft a columns block, I'd read it, push back on something that sounded too much like a startup landing page, and it would revise. The philosophy pages in particular went through a few rounds. The Honest answers FAQ on the Why Chinaski page ("What can't Chinaski do?") is the kind of copy that's hard to get a model to write without hedging, but it got there.
What broke
Two things needed fixing after the initial build, and both were instructive.
The mobile header was a mess. The nav had no hamburger menu. On small screens, the full navigation just stacked vertically and stayed open all the time, including every dropdown submenu simultaneously. That's a CSS issue in the theme, not a Chinaski issue, but it's the kind of thing that's easy to miss when you're building in a desktop browser. Adding a hamburger toggle with a small JS snippet fixed it. The theme is just Template Toolkit and CSS, so the fix was a straightforward edit to two files.
Eight nav items were pointing to 404s. The cause: pages with a parent in the page hierarchy build to nested paths (/en/about/features/ rather than /en/features/) but the nav items had been created with the flat paths. Fixing them was eight update_nav_item calls. The nav URL structure is something the admin should probably warn about; I've filed it as a known gap.
What it demonstrates
The point of building this site with Chinaski wasn't just to save time, though it did. It was to close the loop on the MCP claim. The docs say an agent can manage your whole site through a typed tool interface. That's a specific claim, and it's easy to make it about a toy example. This is a production site with real content, real navigation, and real languages, and it was largely built by an agent in an afternoon.
The static output also performed exactly as expected. Build time on a $5 VPS is under two seconds for the full site. The live pages have no app layer and no JavaScript. A search for Chinaski in a browser's network tab on any of these pages shows a single HTML document, a CSS file, and the fonts. That's it.
The rough edges are real. The nav URL issue in particular is something a new user will hit. But none of them required touching the Chinaski core. They were theme edits and data fixes. The tool did what it's supposed to do.