How to Build a Newsletter Signup Page Without Code
A newsletter signup page without code needs three things in the prompt: what the newsletter is about, how often it arrives, and a single email field. Zugo builds the page in about a minute and publishes it to a live address. The one decision you must make yourself is where the collected addresses go.
That last part is where most first attempts quietly fail. A form can render perfectly and still send submissions nowhere, and nothing on the page tells you. This guide covers the prompt, the three storage options, the honest gap between a signup page and an email platform, and what the whole thing costs.
What actually makes a signup page work?
A signup page trades something for an email address. If the trade is not stated, the page collects nothing. "Subscribe to my newsletter" is not a trade. "Every Thursday, one short breakdown of a shipping mistake I made that week" is, because the reader can picture what lands in their inbox.
Three lines carry the whole page: the promise, the frequency, and the proof that you actually send it. Frequency matters more than writers expect. "Weekly" sets an expectation the reader can accept or reject in one second, while an unspecified cadence reads as "as often as I feel like it", which most people decline.
Proof can be small. A link to the two most recent issues, a one-line count of current subscribers if it is not embarrassing, or a screenshot of a real issue all work. What does not work is inventing numbers. If you have 40 subscribers, say what the newsletter covers instead of how many people read it.
What should the prompt include?
Keep the page to one screen and one action. Everything you add below the fold competes with the field you actually want filled.
Build a single-page newsletter signup.
Newsletter: [name], about [topic] for [audience].
Frequency: [every Thursday].
Promise: [one specific thing the reader gets in each issue].
Above the fold: headline, one-sentence promise, email field,
button "[Get Thursday's issue]".
Below: three past issue titles with one line each, and a short
"what you are signing up for" note.
Form: email only. Show a thank-you state after submit.
Tone: direct, no marketing adjectives.
Two details in that prompt matter more than the rest. Naming the button after the outcome, "Get Thursday's issue", performs better than "Subscribe", because it describes what happens next. And specifying a thank-you state avoids the worst first-build bug: a form that submits and then looks exactly as it did before, so the reader signs up three times.
If you want the signup to sit inside a longer page rather than stand alone, the same prompt rules apply. The AI landing page guide covers the multi-section version, where the signup block is the last thing on the page rather than the only thing.
Where do the email addresses actually go?
This is the real decision. A generated form needs a destination, and Zugo gives you three reasonable ones. They are not equivalent.
| Destination | How it works | Best for | What you still handle |
|---|---|---|---|
| Resend connector | Each submission is emailed to your inbox | Under ~200 signups, low volume | Copying addresses into your mailing tool by hand |
| Supabase connector | Each submission is written to a table you own | Any volume, you want an exportable list | Exporting the table when you send an issue |
| Your existing email platform | Point the form at the signup endpoint your provider gives you | You already send with a real ESP | Setup on the provider's side |
If you already pay for an email platform, the third row is almost always right: let the tool that sends the newsletter own the list. If you are starting from zero, Supabase gives you a table you control and can export later, which is the least regrettable default.
Whichever you pick, test it from your phone before you share the link. Submit a real address, confirm it arrives where you expect, and only then publish widely. The mechanics of wiring form destinations are the same as for any contact form, covered in contact forms on AI-built sites, and the database side is in using Supabase with an AI app builder.
Do you need a double opt-in?
Often, yes, and this is a place where the page alone is not enough. A double opt-in sends a confirmation email and only adds the address after the reader clicks it. It protects you from typos, from fake addresses, and from complaints later.
Zugo can build the confirmation flow: the form writes to Supabase with a pending flag, Resend sends the confirmation email, and the link flips the flag. That is a real application rather than a static page, so it takes a few rounds of edits rather than one prompt, and it costs credits accordingly.
The honest alternative: if your email platform already does double opt-in, use its form endpoint and skip building the flow. Rebuilding a solved problem is the most common way people overspend on a signup page.
What does the page cost to build?
Actions are priced individually. An edit is 3 credits, a build is 6, and a multi-page platform is 12 plus 3 per page. Free includes 5 credits, Pro is $25 a month for 200 credits, and Business is $99 a month.
A single signup page is the cheapest thing you can make here, because it is one build plus a handful of edits. Do check the arithmetic before you plan around the Free tier: one build already costs more than the 5 credits Free carries, so a page you intend to publish, edit, and keep lives on a paid plan.
Publishing puts the page at your-slug.zugo.run immediately. Connecting your own domain matters more for a newsletter than for most projects, because the signup link travels in other people's posts and a branded address gets clicked more.
What will Zugo not do for your newsletter?
The page is not the newsletter. Being clear about the gap saves you a wasted evening.
It does not send campaigns. Zugo builds and hosts the signup page and can send transactional email through Resend. Composing an issue, scheduling it, segmenting readers, running A/B subject lines, and handling bounces are jobs for an email platform. Dedicated tools are genuinely better at this, and there is no reason to fight them.
It does not manage consent for you. GDPR, CAN-SPAM, and the unsubscribe requirements that come with them are your legal responsibility. The page can carry a consent checkbox and a privacy link because you asked for them, not because the builder knows your jurisdiction.
It does not guess your deliverability setup. Domain authentication, SPF, and DKIM live with your sending provider and your DNS, not with the page.
It is not a substitute for a development team on anything genuinely complex. A signup page is not complex, which is exactly why this approach fits it.
Publish first, refine after
The fastest version of this project: one build, one destination connected, one test submission from your phone, publish. Everything else is an edit you can make after real people have started arriving.
The code is not locked away either. Zugo exports to GitHub as an ordinary repository, so if the signup page grows into something bigger, a developer can take it from there. If it grows in the other direction, toward selling something rather than just collecting addresses, building an online store without code picks up where this leaves off.
Start the first prompt at zugo.dev.