To set up email for a new SaaS, list the messages your product needs and decide which service owns each one. Keep working login and billing emails in place. Then add one onboarding journey with a clear trigger and a condition that stops it when the user finishes.
That plan makes the provider decision easier. “We need email” can mean sending a password reset within seconds or helping someone return to an unfinished project tomorrow. The second job needs product state and timing rules as well as delivery.
Which emails does a new SaaS need?
Start with the messages necessary to use the product, then add lifecycle email where a message helps the user complete something. You don't need a long sequence at launch.
Copy this table into your project notes and replace the examples with your own product:
| Email job | Trigger, owner and stopping point |
|---|---|
| Login or password reset | Starts with a request for access. Check your authentication service first. The message is unnecessary if the request has expired or been used. |
| Receipt or billing notice | Starts with a confirmed billing event. Check your payment system or existing sender. Don't send a second notice if another service already sent it. |
| Setup guidance | Starts when a registered user has an unfinished first task. Your lifecycle email system owns the reminder. Stop it when the task is complete. |
| Project reminder | Starts when a user creates something but hasn't reached a useful result. Your lifecycle email system owns it. Stop it when the result is reached or the project is removed. |
| Product announcement | Starts with a relevant update. Your campaign tool owns it. Exclude people outside the intended audience. |
“Owner” means the service responsible for sending that message. Your app may use more than one provider, but each message should have a clear owner. Otherwise, adding a new tool can give a customer two welcome emails.
Keep service messages and marketing messages separately identified in the plan. Record the actual preference data your product has and check the provider's requirements for each message type.
How do you choose an email service provider?
Choose an email service provider, or ESP, against the jobs in your inventory. Check what you already have before adding another integration.
If your authentication provider already sends working login links, preserve that path while you add lifecycle messages. If your payment system already sends receipts, decide whether there is a reason to move them.
For onboarding, ask how the provider uses completion events to stop pending reminders. Verify that behavior with your product's real activation milestone.
Also compare who will maintain the program. Some teams want to edit workflows directly. Others want their coding agent to configure proposed email plays and keep the event integration accurate. barua supports that agent-led setup through its installation guide.
Write down the work that remains after the first send. A tool that sends your test email still needs accurate events when the product changes.
For a team without a dedicated marketer, the lifecycle platform comparison gives you an evaluation exercise built around that ongoing work.
What needs to be ready before the first real email?
Choose the sending domain and a reply address someone will read. Follow your provider's current domain-verification instructions and confirm that verification succeeds before using real recipients.
Have your agent inspect the existing DNS records before proposing changes. Keep the records used by your current mailbox and other senders. The provider's guide should determine which authentication records to add; copying another product's configuration won't verify your domain.
Check what happens after sending too. A failed delivery should be visible to whoever owns email. Marketing messages need a working unsubscribe path that updates the preference used by future sends. Test a reply and an unsubscribe with your own recipient before starting the onboarding journey.
What should your first onboarding email do?
Choose one action that brings the user closer to a useful result. Then write the email around the part they have left to do.
Suppose your product builds websites. Creating a draft site is progress. Publishing it is the first result. A reminder could help a user who created the site but hasn't published it.
Define the journey in plain language:
After a user creates their first site, wait two days. If they still haven't published it and marketing email is permitted, send one message linking to the publishing step. Stop the reminder when publication is recorded.
Two days is a starting choice for this example, not a benchmark. Choose the delay based on how long the task normally takes and what you know about your users.
An illustrative email might read:
Subject: Ready to publish your site?
Your draft is saved. Open the publishing screen to choose the address people will use to visit it.
Open publishing
The button needs to reach that user's actual task, including the correct login redirect if they are signed out. Have your agent check the destination through the product. A homepage link makes the user find the task again.
Which events do you need?
For the website example, the email system needs the registration and site-creation facts. It also needs the publishing milestone so it can stop reminders. The server should report each fact from the code that records it.
Write the product meaning before selecting event names. “Activated” is too vague on its own. “The first site is publicly reachable after a successful publish” tells your agent what to find and tells you what to test.
In barua, signed_up establishes the user. The site can be described by created, with activated representing the first useful result. The exact fields belong in the maintained event contract.
If the server cannot observe the completion step, fix that gap before launching its reminder. Missing data can make a completed user look unfinished.
Use the lifecycle event worksheet to record each fact and its source.
What should you test before launch?
Test the recipient's whole journey, including the cases where the message should stop. A successful event request alone doesn't prove that the right email reached the right person.
- Run a new user through the real product path using a test recipient you control.
- Confirm that the message uses the intended sender and opens at the correct task.
- Complete the task before the reminder is due and check that the reminder doesn't send.
- Complete it while a message is waiting for its sending window and check that case too.
- Retry the same event and check that it doesn't produce another reminder.
- Record a marketing refusal and verify that the reminder stays off.
Use the provider's test environment where it supports the case. For any live delivery check, isolate the audience and verify the actual message received. Save enough evidence to repeat the check after the integration changes.
What should you give your coding agent?
Give the agent the email plan and ask it to inspect the current implementation before choosing what to build. This starting prompt leaves the product decisions visible:
Inspect this product's existing email setup.
List the messages it already sends and the service that owns each one.
Keep those working paths in place.
Find the server-side fact that marks our user's first useful result.
Propose one onboarding reminder and its completion condition.
Show the real source of each required event and flag any missing data.
Explain the recommendation in plain US English. Use concrete product
facts and short paragraphs. Don't invent results or add generic claims.
Give me the implementation plan and the tests before enabling sending.
If barua fits that plan, the setup instructions give the agent the current procedure. barua is in early access, with access available through the homepage.
The barua onboarding walkthrough explains the setup sequence and the delivery checks to run.