AI App Builder With Resend: Email From Your Own Domain
AI App Builder With Resend: Email From Your Own Domain
Resend is one of the built-in integrations in Zugo. Connect it, and a generated project can send real email: a notification when a form arrives, a confirmation to the person who filled it in, a receipt after a payment. The account and the sending domain are yours. The builder wires the sending, not the reputation behind it.
Email is the piece most people forget until the first enquiry disappears. A page that collects an address and tells nobody about it looks finished and is not, and that gap is exactly what this integration closes.
What does the Resend integration do in a generated project?
It gives the project a way to send transactional email, meaning messages triggered by something a user did. A booking request that lands in your inbox. A confirmation that reassures the person who sent it. A password reset. A receipt.
The sending happens through your Resend account, using a domain you control, which matters more than it sounds. Mail that goes out as hello@yourbusiness.com behaves differently from mail that goes out through a shared address belonging to a tool, both in how it looks to the recipient and in whether it reaches them at all.
You describe what should be sent in the same plain language you describe everything else: "when the contact form is submitted, email me the message and send the sender a short confirmation." The agent wires it into the generated code and the sandbox boots the project before you see it, so a build that fails to open is reported rather than handed over.
What the integration does not do is turn your project into a mailing platform. It sends the messages your app triggers. Campaigns, segments and unsubscribe management are a different category of product, and pretending otherwise would set you up for a bad month.
What do you need before you connect it?
Three things, and only one of them takes real time.
A Resend account, created on their side, free to open. The plan you need depends on volume, and that arithmetic is between you and them rather than something the builder decides.
An API key from that account, which you paste into the integration in your workspace. This is the credential that lets your project send, so it belongs in the connector and nowhere else. It should never appear in text you paste into a chat, a screenshot, or a public repository.
A domain you can edit DNS for. This is the part that takes an afternoon rather than a minute, because verification means adding records that prove you own the address you are sending from. Until that is done, your mail either does not go out or goes out looking suspicious to every inbox that receives it.
If your project is still on its yourproject.zugo.run address and you have no domain yet, connect the domain first. The email side depends on it, and doing them in the other order means doing the email setup twice. The custom domain guide covers the DNS side.
Which emails should a small project actually send?
Fewer than you think, and each one should exist for a reason you can name.
| Message | Who receives it | Why it earns its place |
|---|---|---|
| New enquiry notification | You | Without it, a form is a black hole |
| Confirmation to the sender | Your visitor | Stops the "did that work?" follow-up email |
| Booking or order confirmation | Your customer | The record they will look for later |
| Payment receipt | Your customer | Expected after money moves |
| Password reset | Your user | Required the moment accounts exist |
| Weekly digest of activity | You | Useful only once there is activity to digest |
The first two are the pair that most small sites need and most small sites skip. A notification without a confirmation makes visitors resend the same message three times. A confirmation without a notification means the visitor is calm and you never find out they wrote.
Everything below the middle of that table depends on what the project does. A brochure site with a contact form needs two rows. A booking tool needs four. A product with logins and payments needs all six, and by then email has stopped being a detail and become part of the product.
Why does the sending domain matter so much?
Because inbox providers decide what to do with your message based on who is vouching for it, and an unverified sender vouches for nothing. Verification through DNS records is how you tell the receiving side that this domain authorised this service to send on its behalf.
Skip it and the outcome is not a clear error. It is worse: messages that leave successfully, report as sent, and land in spam. You will believe the feature works because your own test arrived, since your own provider trusts you more than a stranger's does.
The practical consequence is that email is the one integration you must test from outside your own world. Send to an address on a different provider than your own, ideally two, and look in the spam folder rather than only the inbox.
It also means the reply address deserves a thought. Mail sent from a no-reply address that nobody monitors trains people not to respond, which is a strange thing to build on purpose when the entire point of the form was starting a conversation.
What does adding email cost in credits?
Wiring email is generation, so it is priced like any other work in the builder. An edit costs 3 credits, a fresh build costs 6, and a multi-page platform costs 12 for the first three pages plus 3 for every page after that. Hi-Fi mode doubles both, so a build is 12 and an edit is 6.
In practice, adding sending to an existing project is one edit, and refining the wording of the messages is another edit or two. Most people spend more credits on the layout of the form than on the email behind it.
The plans are simple. Free includes 5 credits, Pro is $25 per month for 200 credits, and Business is $99 per month for 800. Two hundred credits comes out to roughly 16 platforms, 33 builds or 66 edits when you spend them on one kind of action.
The cost of the messages themselves is separate and belongs to Resend, on whatever plan you chose there. That separation is deliberate and it works in your favour: the sending account is yours, so your sending history and your domain reputation are not tied to a subscription with the builder.
How is this different from a form that only stores submissions?
A stored submission sits in a database until someone opens it. An email arrives. That difference decides whether an enquiry gets answered the same day or the following week.
The two are complements rather than alternatives, and the strongest small setup uses both: write the submission to a table so nothing is ever lost, and send a notification so you find out immediately. If the mail fails, the record survives. If the database is slow to check, the mail already reached you.
Storage comes from the database side of the stack, which is covered in the Supabase integration. Sending comes from Resend. Asking for both in one prompt is normal and costs no more than asking for either.
The other half of this question is what the form itself should ask for, which is a design problem rather than a plumbing one. The contact form guide covers the fields worth keeping and the ones that quietly cost you replies.
What does the integration not cover?
Four things, said plainly.
Deliverability is not guaranteed by anybody. Verification and a clean domain move the odds strongly in your favour, and no service, builder or otherwise, can promise a message reaches an inbox. Anyone promising that is selling something.
Marketing sending is a different discipline. Consent, unsubscribe handling and list hygiene carry legal weight in most of the world, and a transactional integration is not the tool that manages them.
Volume limits and pricing belong to your Resend plan. The builder does not raise or lower them, and a project that suddenly sends far more than usual will hit their ceiling rather than a Zugo one.
And the general boundary applies here as everywhere: a builder does not replace a development team on a complex product. Elaborate rules about who receives what, retries after failure and audit trails are engineering work, reached through edits and eventually through a code export, not through one description.
Where to start
Connect the domain, verify it, then ask for the two messages that matter: a notification to you and a confirmation to the sender. Test both from an address on a different provider, and check the spam folder before you call it done.
Once that pair works, everything else is an increment. Receipts follow payments, resets follow logins, and each is one edit at a time rather than a project of its own.
You can build a project, attach a domain and wire email into it in one sitting at zugo.dev. Start with the form you already wish someone had answered.