How to Build a Blog Without Code: A Practical Guide
To build a blog without code, describe four things in plain text: the post list, the layout of a single post, an about page, and a contact form. Zugo generates the whole set, boots it in a sandbox, and publishes it to a live address. A multi-page build starts at 12 credits.
The hard part of a blog is not the first build. It is the second month, when you have twelve posts and need to add the thirteenth without touching code. This guide covers both: the prompt that produces a usable blog, and the honest answer about what happens after launch.
What does a blog actually need on day one?
A blog is four screens, not forty. The post list carries titles, dates, and short excerpts. The post page carries the article itself, with headings, images, and readable line length. The about page tells a reader who is writing. A contact form gives them somewhere to reply.
Everything past that is optional and worth postponing: tag pages, author bios, a search box, related posts, comments. Adding them later is a normal edit. Adding them upfront makes the first build slower and gives you four screens you have not yet decided you want.
Reading width matters more than anything decorative. A blog lives or dies on whether the body text is comfortable at 900 pixels and on a phone. Say so in the prompt, in those words, and you will not spend the evening fixing typography by trial and error.
What should go in the blog prompt?
The builder fills every gap you leave with a guess. Three gaps matter: what the blog is about, who reads it, and how a post is structured. Name those and the first draft comes back close enough to edit rather than restart.
Build a blog about [topic].
Audience: [who reads it and what they want from it].
Pages:
1. Home: list of posts with title, date, 2-line excerpt. Newest first.
2. Post page: title, date, body text with H2/H3, images, comfortable
reading width, link back to the list.
3. About: who writes this and why, one photo.
4. Contact: name, email, message.
Tone: [businesslike / personal].
Include 3 sample posts so the layout has real content in it.
That last line does more work than it looks like. A blog rendered with placeholder text hides every layout problem it has. With three real posts of different lengths in place, you see immediately whether long titles wrap badly and whether a short post leaves the page looking empty.
If a blank prompt field is not where you want to start, several of Zugo's 25 templates are close to this shape. Pick the nearest one and rewrite it in plain text. Starting from a template makes the first draft more predictable than starting from nothing.
How do you add a new post after the site is live?
This is the question that decides whether an AI-built blog is a good idea for you, and it depends entirely on how often you publish. There are three workable answers, and the right one is a function of cadence.
| Publishing cadence | How posts get added | What it costs you |
|---|---|---|
| A few posts a year | Ask for the post in chat, it gets written into the site | One edit per post, no setup |
| Monthly | Store posts in a Supabase table, the site reads from it | One-time connector setup, then no builder involvement |
| Weekly or daily | Export to GitHub and attach a CMS or a static generator | Developer time upfront, lowest cost per post afterwards |
The first row is honest about its limit: at one post a week, asking the builder to insert each article by hand gets tedious and expensive before the quarter is out. The second row is where most working blogs land, because a table of posts turns publishing into filling in a row.
The Supabase connector is what makes the middle row possible. You get a database, a login, and file storage, so posts live as data instead of as hard-coded markup, and the blog reads them at load time.
What does a blog cost to build and run?
Pricing is per action, not per month of usage. A multi-page build costs 12 credits, and that flat fee covers the first three pages. Every page past the third adds 3 credits. A blog with a home page, a post page, an about page, and a contact page is four pages: 12 plus 3, so 15 credits.
The Free plan comes with starter credits and no card, which is enough to see a real build of your own idea rather than a demo. Pro is $25 per month and carries 200 credits. Business is $99 per month. A custom domain and the connectors below sit on the paid tiers.
Running costs after launch are the part people forget. The site itself is published and served; what you keep paying for is change. A blog you edit twice a year costs almost nothing to keep. A blog you rebuild monthly is a different budget, which is exactly why the cadence table above matters.
Which connectors does a blog actually use?
Four out of the seven available ones, in practice, and you will not need all four on day one.
Supabase turns posts into rows. This is the single upgrade that changes a blog from a page you edit to a site you publish to.
Resend sends email. For a blog it does two jobs: it delivers contact form submissions to your inbox, and it powers a newsletter signup. Before it is connected, a form renders and submits into nothing, which is the most common reason a new site quietly loses its first readers.
Google Analytics answers which posts are read to the end and which get opened and abandoned. On a blog that is the only feedback loop you have.
A custom domain matters more here than on most project types, because a blog accrues links over years. Moving addresses later means moving that history. Published projects live at your-project.zugo.run by default and a custom domain is available on the paid plans; connecting one is worth doing before you publish rather than after.
How do you keep the blog findable?
Ask for the plumbing explicitly, because it is invisible and therefore easy to skip: a title and meta description on every page, headings in real H1/H2/H3 order, alt text on images, and a sitemap. These are cheap to request in the first prompt and irritating to retrofit across twenty posts.
Speed is the other half. Blogs get slow from images, not from code. Say "compress images and lazy-load anything below the fold" in the prompt and the problem mostly does not appear.
None of this substitutes for the posts themselves. A fast, well-marked-up blog with nothing worth reading ranks exactly as well as it deserves to.
When is a real CMS the better answer?
Three cases, said plainly.
More than one writer. If three people publish, they need drafts, roles, and a review step. That is a content management system's actual job, and a builder-made blog does not replace it.
High cadence. At several posts a week, you want an editor with a preview button, not a chat window. The economics stop working long before the workflow does.
A migration with history. Moving an existing blog with hundreds of posts, existing URLs, and redirects is a data project first and a design project second. Build the new blog here if you like the result, then hand the code to someone: GitHub export gives you an ordinary repository, and the project is yours.
Where this approach does work is the common case: one writer, a few posts a month, a site that should look like it was designed on purpose. Every build is booted in a sandbox before it reaches you, and a build that fails to open is reported as a failure rather than handed over, which lowers the risk of publishing a blank page without removing it.
A simple build takes about a minute; a multi-page blog takes a few. If your next project after this one is a site that takes bookings rather than readers, the same prompt discipline applies with a different data model: see building a booking site without code. Otherwise, describe your blog at zugo.dev and edit the draft it gives you back.