The 60-Day Journey of Building Stan’s Email Marketing Platform
Stan is an all-in-one platform that helps people make a living and work for themselves. We work with content creators who use Stan to host and sell digital products, including courses, webinars, memberships, e-books, and other types of digital products.
When we set out to build our Email Marketing tool, we had 8,000 active paying customers who were making $25M per year on the platform by selling digital products.
After conducting product research and analyzing our inbound channels, we discovered that many of our customers use third-party tools to send emails to customers acquired through Stan. Staying true to our mission of building an all-in-one platform, we have decided to incorporate email marketing into Stan.
Why Build In-House
Sophisticated email marketing tools have been around for over a decade. Headliner companies like Mailchimp and ConvertKit have offered the option to integrate with their APIs, so there was no need to reinvent the wheel. Many of our customers used them.
However, the cost of these tools was 10 times more than what we thought was reasonable. At Stan, we wanted to include Email Marketing as part of our $99 per month subscription tier at no additional cost, so reducing the underlying operating costs was crucial.
As an e-commerce platform, we had already built our email infrastructure on AWS SES. At the time, we were sending approximately 50,000 transactional emails per day, and creating a scheduling system on top of it seemed like a challenge we could undertake.
So, we began building.
“Good artists copy, great artists steal.”
Our first step was to research the leading email platforms in our industry to see how they were built. We learned that email marketing products often rely on third-party vendors to send emails, while the email marketing platforms themselves provide a user interface for composing, organizing, and scheduling emails.
We discovered that most companies in our industry use SendGrid as their email-sending engine. Since our goal was to enable robust functionality rather than innovate. Given that a market leader already exists, we were tempted to rely on peer validation to shortcut our research and go with what has proven to work well for others.
Getting in Touch with SendGrid
As a two-year-old startup, we’re accustomed to building quickly. Decisions are made by the end of the day, MVPs are built by the end of the week, and significant features are shipped by the end of the month.
Since we projected a volume of 100M emails per month, we decided to contact the SendGrid team and connect with the humans on the other side. We couldn’t reach them through their website, so we ended up finding the right contacts through LinkedIn. Approximately one week after we started, we managed to hop on a call with a sales representative.
Partnering with Big Enterprises: The Harsh Reality
It took us three weeks to get in touch with the right people to discuss technical requirements and clarify implementation details for our POC. We first met with a sales representative, who connected us with an account executive, who then connected us with a technical specialist who did not have all the answers, so we routed back to the account executive, who then connected us with a new technical specialist. After three weeks of routing, we finally got what we needed to build a POC and validate our use case.
However, we couldn’t shake off the feeling that something wasn’t quite right. If it took our potential partner three weeks to assist us with onboarding, could we trust them to be there with us if things go wrong in production?
The Cost of Sending Emails
Pricing was another aspect that made us question our peer-validation assumption. SendGrid’s pricing started at $19.95 for up to 50,000 emails, which works out to 0.0003/email. With our projected volume of 1M emails per day, we had an opportunity to reduce these fees by purchasing a high-volume bundle. For example, we could buy a 30M emails/month bundle and access reduced costs per email, but this would come with a risk of overpaying if we didn’t use the entire bundle.
On the other hand, we already used AWS for transaction emails, which offered a comfortable pay-as-you-go model. Additionally, AWS charged 0.00002/email at our projected volume with no strings attached. It felt like an obvious win.
At that point, we couldn’t understand why others chose SendGrid. Was there something they knew that we didn’t?
Building on AWS
In the spirit of true engineering, we relied on first principles and rejected authority and social proof. We abandoned our SendGrid POC and decided to build on AWS.
Since we already used AWS for transactional emails, we could utilize our existing ecosystem to track emails, manage sender data, collect email analytics, and monitor deliverability.
However, there were also downsides. For example, if we wanted to authenticate personal sender emails, like personal@gmail.com, AWS allowed us to customize one part of the email, but not everything, adding a 5-line verification link and a sentence in their default font underneath 🤦🏻.
We also disliked how AWS showed sender routing “via amazonses.com” right next to the sender email. Advertising AWS was not part of our roadmap, and we wanted to stay on brand.
Email Deliverability
When building an Email Marketing platform, nothing else matters more than deliverability. Email deliverability depends on the sender’s reputation, which is based on the underlying infrastructure used to send emails. It takes months to build a good reputation, and one bad actor to destroy it.
With transactional emails, deliverability was less of a concern because we controlled email content. However, with Email Marketing, we can no longer curate what goes inside the emails we send.
It’s only a matter of time before a bad actor decides to send high volumes of email with explicit content to a purchased email list, which would flag us (the sender platform) with all major Email Service Providers. They would then diligently place our emails into spam across our entire user base.
By building an Email Marketing platform in-house, we had to ensure that emails were delivered to primary email folders and avoided spam. We had to build out our processes and automations to protect our email reputation by monitoring and reacting quickly to events affecting our sender authority.
System Design for Email Deliverability
Email deliverability was outside the scope of our expertise at Stan, so we hired a freelancer who specialized in this area. He taught us the basics of Email Deliverability and worked with the team on system design. After 2 weeks, we arrived at the following architecture:
Each user sending an email is persistently mapped to a dynamically generated email address. AWS enables us to create email addresses on the fly, provided that our sender domain has appropriate MX records.
For instance, newuser@a.stanmail.io can be "pseudo" created by simply including it in the from field of an email payload. These pseudo-created addresses do not have a managed inbox, so responding to these emails would result in an "Email doesn't exist" error. In our case, we put our customers' personal email addresses in the Reply-To field of the email payload. This way, outgoing emails were sent from, while email responses would be delivered to newuser@gmail.com (a personal email address) to continue the thread there.
Email Deliverability Takeaways
- Use a separate domain for email to minimize reputation risks. If your email reputation is damaged, your website won’t be affected and will continue to rank well in search engines. For instance, our website was hosted on stan.store while our root email address went through stanmail.io.
- Use subdomains to separate senders and avoid the risk of one bad actor affecting your entire service. We used four subdomains that we dynamically mapped to senders:
a.stanmail.io,b.stanmail.io,c.stanmail.io, andd.stanmail.io. If a bad actor was mapped to badactor@a.stanmail.io, they could only affect the reputation of the “a” subdomain, but not others. More on subdomains and why you should use them. - We determined the number of subdomains using a rule of thumb: one subdomain per 100K unique recipients.
- Ensure that all of your domains are correctly configured to protect your email reputation. You must have DKIM, DMARC, and SPF authentications correctly configured for all your subdomains.
- Associate multiple dedicated IP addresses with each domain. By default, AWS shares IP addresses between customers, which means you could be impacted by IP reputation hits that are completely out of your control. To mitigate this risk, use two dedicated IP addresses per subdomain and always have additional addresses as backups.
- Make sure to warm up all your IP addresses, including backups, before using them.
- Develop processes to update the mapping between users and sender domains based on the individual sender email reputation. For instance, you can group users with bounce rates of less than 1% into a.stanmail.io, those with 2–5% into b.stanmail.io, and so on. This will ensure predictable deliverability and optimize the risk profile across your platform.
- Develop processes to improve individual user deliverability over time. For example, suppose
user1@c.stanmail.iohas a bad email list and a bounce rate of 50%. At the application level, you can create a process that monitors and suppresses bad email recipients, thereby improving the delivery rate over time. As the delivery rate increases, you can move that user to a better-tier domain, and vice versa.
Monitor, Monitor, Monitor
While working on our email deliverability systems, we created a dashboard that allows us to monitor how our email reputation evolves over time.
One month after launch, our delivery stabilized at a 3.9% bounce rate across the entire user base. We found that b.stanmail.io had the worst deliverability and d.stanmail.io had the best deliverability.
We use the High Bounce Volume Users section to monitor the deliverability of individual users and make decisions on which domain they should be coming from. We also identify and remove bad actors from the system.
By staying informed at all times, we feel well-equipped to tackle any challenges that may arise as our usage continues to grow.
Since our public launch, we have experienced accelerated adoption, with an average of 1 million emails sent per week and growing. As the volume continues to increase, we rely on our monitoring systems to proactively mitigate risks. At the same time, we are building intelligent automations to reduce the need for human effort.
Conclusion
Our journey of building our Email Marketing platform has provided valuable insights into the importance of first-principle thinking and innovation.
By questioning the “market standard” and using our expertise, we launched a successful product that met our needs and the needs of our customers.
We hope this case study serves as a valuable example for other companies looking to build better products. By taking an unconventional approach and being willing to innovate, companies can achieve success and meet the ever-changing needs of their customers.
We encourage engineering teams to embrace first-principles thinking and to rely on their expertise when building products. We also advocate for developing in-house skills and having a dedicated team to own and manage your systems.
By following these principles, companies can build products that are efficient, effective, and meet the needs of their customers.
