15 min
Originally published in Russian on Vastrik Club
How I built a custom podcast website in 11 days, with AI and no coding
Part I. Why a website at all
My podcast, Baka!, is seven years old. It started as two beginners talking about anime and grew into a media project: a daily Telegram channel with notes about animation, video essays on YouTube, articles for Kinopoisk and T—J, 120,000 followers on TikTok.
The problem was that all of it lived inside social networks. Which meant it was almost invisible — to search engines and to AI alike. Seven years of conversations about anime existed only inside platforms, each with its own search and its own rules.
A year and a half ago — before AI agents existed — I had already tried to build a site with ChatGPT. I got as far as registering a domain and stopped. The instructions were incomplete. Too much had to be done by hand: copying pieces of code somewhere, working out why the thing that should run didn’t. The model gave advice, often out of date, and couldn’t do the work for me. I suffered for a couple of days and gave up.
Then, two weeks ago, I saw a post by Samat Galimov, who makes Zapusk Zavtra, one of the best-known tech podcasts in Russian. He had built a site for his show, with transcripts of every episode, over a couple of evenings.
So I decided to try again. The idea was this: if you can make transcripts of a podcast, you can make a full catalogue of the whole project, with cross-references. So that you could click on the name of an anime and see everything we’d ever said about it — in posts, in articles, in podcast episodes, down to the minute in the conversation.
That’s where the structure came from: the site is two halves, an archive of material and a catalogue of anime, and what links them is mentions of titles. The address is bakapodcast.com.

Part II. How the work worked
The last time I wrote code was in seventh grade, in Pascal. So I started planning the project straight away in Claude. I didn’t know what tools it could use, what content management systems existed (apart from WordPress), how a static site differs from a dynamic one, or what the limits were. So I asked it to ask me questions.
After several rounds of questions and my extra explanations of the idea — for example, I had to explain transcripts separately and send the Zapusk Zavtra site as an example — Claude proposed a stack: Astro as the site generator, Sveltia as the admin panel, hosting on Cloudflare Workers.
We rejected WordPress and site builders because there are no ready-made plugins for what I had in mind anyway. I would have had to build the same things, only inside someone else’s system.
It’s worth saying that at this stage I kept asking Claude stupid questions. Is this free? Why are we taking this particular admin panel? Will there be any limits on the design? Before making a choice, I wanted to understand why we were doing what we were doing. So much so that for the first few days Claude wrote “Don’t worry, this is free” in almost every message.

Out of those discussions Claude wrote me eight specification documents (by the end of the project there would be twice as many). It explained how to switch on Claude Code and generated the prompt for the first session.
From then on I used exactly that pair: Claude in the browser and Claude Code. The first explained the work to me, turned my ideas into specs and wrote prompts; the second implemented them and wrote the code. All I did was move text from one window to the other.

Out of that grew an idea, at once brilliant and completely obvious: I asked Claude Code to write reports about its work into separate documents. So that I could feed them to the browser Claude afterwards, instead of retelling things in my own words.
That paid off many times over, because if I hadn’t done it, the project would have fallen apart somewhere in the middle. Claude Code would have run out of context, started lagging and redoing what it had already done. Instead I could calmly start new sessions without fear of losing progress.
The first commit — the skeleton of the site — appeared at 14:20 on 5 August. By the end of that evening there were forty commits: the home page worked, so did writing posts and sections, and the site opened on the internet — without a domain and without a design for now.

Part III. Three days of design
The clearest way to explain how vibe coding worked for me is the design of the site. In the original spec Claude generated, the design was supposed to appear by itself: I’d send a couple of references and Claude Code would invent the rest from them. It probably would even have worked. But I wanted more control.
To save money (more on that below), I decided to think through the design separately, in ChatGPT, and hand it to Claude Code afterwards. That was a mistake.
I gave ChatGPT a few sets of references: the design the podcast already had; a home-page layout in the style of a magazine; layout and typography; and an idea of stamps for the anime cards. And I asked it to draw a design based on them. ChatGPT read the style I wanted to arrive at quite accurately:
“The main site looks like a modern cultural magazine. A light paper background, plenty of air, thin black lines, large typography, but without excess decoration. The home page uses an editorial grid with materials of different weight rather than standard cards.”
But what it could draw was only an approximation of a page. Every generation differed in the details. It couldn’t carry my precise corrections into new versions. After several fruitless attempts it suggested working with HTML files instead of generating images. Great, exactly what I need, I thought (the problems didn’t end there).

With HTML things went faster. I asked ChatGPT to draw a page, gave it corrections, it redrew — and so on until I was happy with the result. The home page took me eight iterations, the article mockup four. When we had made (as it seemed to me) all the pages, I asked ChatGPT to write a document describing the rules of the design system: which spacing where, fonts, blocks and so on.
Then I went to Claude, handed it ChatGPT’s work and asked it to fix any mistakes. Well. Claude simply destroyed ChatGPT’s work. Just one example:

I spent the next four hours getting Claude to remake all the mockups according to the rules ChatGPT had written for itself and then failed to follow. In the end, on top of those eight iterations of the home page, there were another eighteen builds of the whole site from Claude.
And even then I hedged. Before handing what seemed finished to Claude Code, I asked a separate chat whether I had prepared all the pages needed for development. Guess the right answer: of course not. It turned out I had forgotten the error page, the states of the audio players, what links look like and a dozen other small elements you don’t even think about when you look at a site with an untrained eye.
That still wasn’t the end. It’s one thing to draw mockups and quite another to transfer them correctly into code. The transfer took me the next two days, thirty Claude Code sessions and more than 20% of all the edits in the project. That is: drawing the whole design took an evening. Making it work took two days almost without a break.

Why so long? An example. The site has a divider, a separating line. Simple, you’d think: one line, the same on every page. In the mockup it’s one picture. In code it took six attempts over two days. Each time it turned out some other element also drew that line, one nobody had thought about: the border around the search box, the seek arc on the player, the edge of a pull-quote. One page of text from the original mockup turned into five different ones — with a cover and without, with a transcript and without, with video, on a phone. A mockup shows one state; a site needs all of them. If you don’t tell Claude Code what those states should look like, it will invent them itself. And not always the way you need.
That is probably the main rule of vibe coding: you can not know how you want your task done, but you absolutely must understand what the task is. And what the result should look like.
Part IV. The big problems
The real difficulties appeared only towards the end. When the site already worked, looked decent and could be used. Because I started moving in the content and giving it to friends to scroll through.
And it turned out the site didn’t open in Russia. It was hosted on Cloudflare, which Claude had picked on day one, and that was a time bomb. Since June 2025, sites that run through Cloudflare have barely opened in Russia: the state internet regulator, Roskomnadzor, restricts not individual sites but the service itself, so everyone who lives there gets hit, regardless of content. For a podcast whose audience is mostly in Russia, that’s a site nobody can see.

I had to find a way around it, fast. The first idea was to move everything to the hosting I’d bought for embedding video. But it turned out that was blocked in Russia too, by exactly the same logic.
What saved me was that the site is static: Astro doesn’t run anything on the server, it builds ready HTML files in advance, which just need to be laid out in folders. A folder like that can be put anywhere — including in two places at once. So I put it in Yandex Object Storage. It can serve static files straight to the browser, it’s Russian and therefore not subject to the restrictions, and it plugs into Yandex Webmaster, the Russian equivalent of Google Search Console. The move took another day.
After that, loose ends kept appearing. In a couple of days I used up Yandex’s free quota of operations, because I hadn’t thought in advance that they needed optimising and Claude Code hadn’t thought of it by itself — luckily the cost came to a few rubles. Then all the videos moved there too from the original hosting, because dragging them across two platforms every time turned out to be more expensive than storing them in one place.

The funniest problem appeared the day before launch. On 13 August I spent the whole day in the admin panel, sorting through the archive of posts moved over from Telegram. The admin panel is built so that every save is a separate record in GitHub: you press “save”, and the edit goes straight to the code repository. Over the day I racked up 512 such records. To GitHub that looked not like a person working but like a bot, and its anti-abuse protection flagged my account as spam. The admin panel stopped saving, the site stopped updating, and I was left with half the posts unedited. Panic, sadness, postponing the launch — all of it looked inevitable.
I immediately started asking Claude what to do. Wrote to support (the reply still hasn’t come), thought about connecting a different account to the admin panel (the AI talked me out of it), and in the end the workaround turned up by accident. It turned out that although the admin panel couldn’t push changes to GitHub, the Claude agent could! So we ran the admin panel on my computer, locally, and it started saving changes not to GitHub but straight to disk. I edited as much as I needed, and then sent everything at once with a single command through Claude Code. My edits went up in one piece: eight thousand lines at a time.
I even had to write this situation down as a separate rule in the project’s instructions, because Claude Code kept forgetting about it and publishing the site the usual way, which is how I twice looked at the old version and said nothing was working.
And because of it, right now I have to add posts and podcast episodes by hand. Even though Claude and I designed an almost fully automated system.
Part V. Robots that work on their own
Here they are, left to right:

The site now has nine robots working on it (or rather, they will, once GitHub unblocks me).
The first is the podcast robot. Every morning it checks whether there are new episodes in the RSS feed and, if there are, creates a draft on the site — with a title, a player and a description.
The second is the transcript robot. If there’s a new episode, it takes it and runs it through ElevenLabs Scribe. In the transcript it places timecodes and can tell the hosts apart by the pitch of their voices. It puts the result into the same episode draft.
The third is the cover robot. It cuts the character out of the cover of each new episode so they look good on a transparent background. And adds it to the same draft.
The fourth is the Telegram import robot. Every six hours it goes into the podcast’s channel and collects new posts. It turns them into drafts: with a title, a cover and text. If a post has several images, it makes them into a gallery. And it automatically replaces links to other Telegram posts with links to the same material on the site.
The fifth is the tagging robot. It automatically checks all new drafts on the site against the anime catalogue. If it sees a match, it puts links to the titles into the posts (and the transcripts) by itself.
The sixth is the new-titles robot. It’s run by hand and goes through new posts. Its job is to find mentions of anime that aren’t in the catalogue yet. It checks words in quotation marks first, but goes through the rest of the text by its own rules too. If it finds matches, it writes them out on a separate page in the admin panel, where I can mark by hand which of them are anime (Death Note) and which aren’t (Shrek).
The seventh is the catalogue robot. It picks up the mentions of new titles and builds pages for them in the catalogue. It takes the information from two sources, Shikimori (a Russian anime database) and AniList, in case one of them gets blocked.
The eighth is the grammar robot. Russian nouns change their endings depending on the case, so a title can appear in a text in half a dozen forms. This robot generates all the forms of each new title so that a mention is found whatever form it’s in.
The ninth wakes up once a day and updates the Russian copy of the site.
Besides these, Claude Code and I wrote a few one-off robots. One, for instance, collected my old articles from DTF, a gaming and pop-culture site, and another laid them out by template. Without the robots, going through almost fifteen hundred drafts would have taken me far longer than three days.
So my work on the site now comes down to checking the drafts and mentions the robots have prepared and approving them for publication. Minimum manual labour, maximum automation.
(A reader asked whether the robots are AI agents. They aren’t: Claude took part only when they were written; after that everything runs by itself. Some of them hang on Cloudflare cron triggers — scheduled publishing, the RSS check, updating the Russian mirror. The rest run on cron on a small Hetzner server: everything slow and heavy, like transcription through the ElevenLabs API, cutting the character out of the cover, the Telegram import. Of all nine, only two call an AI: the transcript robot and the cover robot. The others are ordinary code — parsing RSS, requests to Shikimori and AniList, finding titles in text against a dictionary, generating word forms. To save tokens and not run to the neural network more than necessary.)
Part VI. And how much does it cost?
Far less than a programmer’s work — not to mention the designer, the front-end developer, the editor and the two or three other specialists you’d have needed for a job like this before.
The Claude subscription is $20 a month. I raised the plan to $100 as a one-off. If I’d stretched the work over a month or two, I’d easily have fitted into the basic price.
The ElevenLabs subscription for transcripts is $22 a month. That was enough even for the insane volume of 143 archive episodes (140,947 lines) without paying extra.
The domain, bakapodcast.com — about €10 a year, bought on porkbun.com.
Yandex Cloud — about 20 cents, for exceeding the limit of 10,000 operations a month. Most likely it will come to under €3 a month even with thousands of visitors. I may need to buy more storage later, but our videos mostly go out on YouTube and the audio lives on Mave, our podcast host, so the free tier covers the images for now.
Unnecessary spending: Hetzner hosting, €9 a month.
Astro, Sveltia, Cloudflare, GitHub — free.
Total: building the site cost roughly €130, and running it costs about €40 a month (or around €20 if you unsubscribe from Claude).
Part VII. The result
The site came together in eleven days. That’s 87 Claude Code sessions, 628 messages from me in the terminal and about a hundred hours at the keyboard. The site now holds 143 podcast episodes with full transcripts, almost a thousand posts and a catalogue of 507 titles with 14,286 mentions across the material. The thing it was all for works: you click on the name of an anime and see everything we’ve said about it — in notes, in articles and in episodes, down to the minute in the conversation.
It lives at bakapodcast.com, and for Russia there’s a copy at ru.bakapodcast.com.
Having finished this version, I’m already thinking about what to add next: social features — comments, ratings, achievements for titles watched and episodes heard. And I’m absolutely sure it’s within my reach.
By the way, in the podcast trailer that opens this text, the only thing not made by AI is the sound of the keyboard. Everything else — the music, the animation and, as you now understand, the site itself — is Claude’s work.