top | item 37596253

Launch HN: Loops (YC W22) – Email for SaaS Companies

151 points| chrisfrantz | 2 years ago | reply

Hello HN! We're the team behind Loops (https://loops.so), a platform aimed at simplifying the email experience for SaaS companies. We support creating and sending marketing, product, and transactional email.

Email is important but painful to manage. If you've ever dealt with the frustration of coding emails by hand, testing them across multiple clients, or integrating them into various SaaS tools, you might find our approach interesting.

We make it simple to design and send email to your users either manually in the app, via API or triggered via an integration. We offer unlimited team seats, so your product team can help align copy, your marketing team can send newsletters, your revenue team can work on dunning and your engineers can have a solid API to help orchestrate the sends.

Most of our competitors use email editors that are licensed from a third party. Our editor is built from the ground up on the Lexical text editor from Meta, extended beyond just text nodes. It supports mobile editing and dark mode, and it autosaves your changes.

Our REST API is straightforward, and we have integrations with tools like Segment and Census. Documentation is available at https://loops.so/docs. On our homepage, right under the fold, we list endpoints and sample payloads.

One issue we've worked hard to address is email compatibility across devices and platforms. It's a problem full of edge cases that we've mitigated by extending MJML, a markup language designed for responsive email, to be even more compliant across different platforms. We don't think you should have to code and test your emails. Email copy shouldn't live in your codebase.

If you're concerned about spam, we are too. We educate our users on CAN-SPAM rules and automatically add compliant footers to emails. We actively monitor to ensure our platform isn't used for spam, and we do not allow cold sales emails.

Our pricing is upfront and available on our website. You can try the platform for free without a credit card. We launched publicly a week ago. We're really interested in any technical feedback you have, as we aim to make this tool as developer-friendly as possible.

Looking forward to hearing your thoughts!

137 comments

order
[+] santiagobasulto|2 years ago|reply
Congrats on the launch. I’m currently starting my own startup, so I can give you my impressions as a potential customer.

Contact-based pricing is bad. You’re trying to create an email platform for SaaS, from the features perspective (yey!) but you’re charging just as mailchimp and everybody else does (nah!).

Instead, as a founder, I’d rather prefer “active user”. If someone tries my product, but they never return, I don’t want to be charged for. So, in any given month, count how many people I have emailed (during that period), and that counts as pricing.

Just my 2c. Good luck!

[+] chrisfrantz|2 years ago|reply
Yep it’s great feedback! You can pretty easily slim down your contact count to follow that active user model if you’d like already :)
[+] daniel_sushil|2 years ago|reply
This is something I definitely struggled with for a few apps I have built in the past. This will come in super handy for my current app.
[+] winrid|2 years ago|reply
I have no idea what contacts means in your pricing. Everytime I send a transactional email to a new address is that a new contact?? Pass on that. Mailgun and Brevo don't bill on that...
[+] mrweasel|2 years ago|reply
That's one thing I never understood about email service providers, the weird obsession with "contacts". I don't care, they are just email addresses. I might need to email a customer once or twice, that doesn't make them a contact. If a service insist that each email needs to be a contact, I'll just add and remove the contact before and after each email sent.
[+] siva7|2 years ago|reply
They're targeting SaaS and SaaS means traditionally a signup is needed to be a customer which turns into a contact.
[+] adamkaz|2 years ago|reply
We're trying a different model - pay for your core audience and any emails (product updates, user touch points, and transactional) are all included. If you have a use case that sends outside of your core audience (maybe sharing content with non-users of your product, we bill on a more traditional email volume pricing.
[+] MattyMc|2 years ago|reply
Pricing page: “(actually) simple pricing”.

Also: More than 5000 contacts, “CONTACT US”.

[+] shash7|2 years ago|reply
Had the same question. Moved to useplunk afterwards.
[+] adamkaz|2 years ago|reply
yah sorry, there is a button there "view all pricing plans" that will get you up to 100k contacts.
[+] mfkp|2 years ago|reply
My company has 500k+ "contacts", but we rarely send emails. It seems to me like your pricing can't work for me, so I'll stick with Brevo/SendInBlue until you decide to change that pricing.
[+] alx-ppv|2 years ago|reply
I don't get why the pricing is based on contacts. Why not charge based on emails sent? This is probably where most of your expenses are, instead of charging on storing contacts in the DB and querying them. I have a SaaS B2C with more than 10k contacts and I don't send lots of emails.

That's why Sendy is a good option for me.

[+] adaml_623|2 years ago|reply
We starting using your API for light volume transcriptional emails a few weeks ago and honestly the integration process was so smooth it was anticlimactic. It just all worked.
[+] chrisfrantz|2 years ago|reply
that's what we're hoping happens! it should just work so you can get back to work

thanks for giving us a try :)

[+] candiddevmike|2 years ago|reply
Do you send emails directly or are you using a separate service like Mailgun? Do you provide dedicated IPs? How do you guarantee delivery and avoid being blacklisted?

FWIW, your service seems priced in a way that encourages spam (send unlimited emails to an address).

[+] adamkaz|2 years ago|reply
Right now we're using AWS SES for our MTA. We've had a pretty great experience with them to date. We don't currently offer dedicated IPs but we likely will in the future. When we do, we want to make sure that customers have the required send volume to actually see a benefit from using one. I think a lot of services offer dedicated IPs too early as a panacea for increasing delivery rates. What we've noticed is that these initial IPs are warmed up so perform well, but over time, if the send volume is too low, it's reputation can atrophy.

We monitor our delivery platform wide and proactively contact customers if there are issues with their account.

As far as spam, yes, we allow you to contact within your own audience as much as you like but we do monitor this for abuse.

[+] tomahony|2 years ago|reply
This is a cool product, but it feels a bit confused.

It seems the innovation here is making the management, editing and publishing of emails much more streamlined through your interface. That's great as it's definitely a frustration of creating emails.

But in the pricing you are focusing on contacts (and therefore "number of emails sent"). First of all, it's very difficult to guess what "contacts" are when considering transactional emails. What if a new user signs up but never uses the app again? Is that a new contact? If I send one marketing email it could be to 200k contacts, but I may only have 1000 transactional emails/contacts per month.

Instead of focusing the pricing around contacts and "emails sent" why not allow customers to "bring their own email platform". This would absolve you of having to worry about email pricing. A custom can connect SendGrid, MailGun or whatever they want. You can then focus your product on the publishing experience (and probably charge a lot more)

[+] chrisfrantz|2 years ago|reply
Thanks for the detailed feedback! We find that users start their company, use us for everything then never have to think about how to contact their users. Requiring a bring your own solution is great for more mature businesses but we’re targeting early stage right now and asking someone to signup for a second service to use ours feels like it may slow things down.
[+] pembrook|2 years ago|reply
Wondering how this differs from something like Customer.io or Userlist?

Have some friends also working in a somewhat adjacent space (Audienceful) so will be watching you guys closely.

But in general it seems email is pretty crowded these days and a lot of the sub-niches are also pretty crowded (eg. Klayvio in ecomm, Customer.io in Saas, Substack/ghost in newsletters, Convertkit for wordpress bloggers, etc).

And for the most part all these apps are just sending on the big API-based senders under the hood (Eg. Amazon SES or Sendgrid). Even the newcomer API-based senders like Resend are just a wrapper around Amazon SES. Which makes any claims around differentiated deliverability on any email platform dubious at best.

Is the plan to build your own sending infra long term?

[+] chrisfrantz|2 years ago|reply
I would like to! It’s probably a bit further down the line for us.

You can do a lot to improved deliverability once you approach it at a platform level. We have access to various datapoints at scale that we can use to help individual users improve their deliverability vs working directly with the sending infra. Beyond that, we offer a platform that helps reduce pain and friction that might exist with more barebones, infrastructure focused services.

[+] deofoo|2 years ago|reply
They offer a free plan :)
[+] rusl1|2 years ago|reply
It looks interesting but where is the pricing section? Do I have to contact you to know how much I will pay? That's a big deal for me
[+] xmattx|2 years ago|reply
Any plans of open sourcing your MJML extensions? We hand-code MJML for our mails and fairly frequently run into compliancy problems.

Runs kinda counter to your business-case I suppose, but might help someone (me) out :)

[+] adamkaz|2 years ago|reply
Its definitely come up! I think it would be cool to have a community working on the translations to MJML from Lexical. There are so many corner cases and email clients out there, it's definitely a challenge to get things working everywhere. What type of compliancy problems have you run into?
[+] chrisfrantz|2 years ago|reply
I would really like to eventually open source core parts of Loops.

I think parts of the editor makes sense, including the MJML. We spent an entire weekend extending MJML for Superhuman and it would be cool to release that work some way.

[+] ponyous|2 years ago|reply
Can you elaborate on compliancy problems? Really curious as I quite like MJML.
[+] acomms|2 years ago|reply
This is good timing. Currently evaluating email send for a new app.
[+] adamkaz|2 years ago|reply
Cool, let us know how we stack up!
[+] petecooper|2 years ago|reply
Personally, I find the Product Hunt upvote stuff front & centre to be quite distracting (and verging on devaluing to the product offering, in a lot of cases).

I understand the reasoning for it being there, but perhaps kick it further down the page so the service / offering is the focus.

[+] chrisfrantz|2 years ago|reply
Totally fair, we just launched a week ago (and it went well) so we wanted to keep it up till the end of the month.

Will certainly place it in the footer and switch off the upvote portion in the future.

[+] j45|2 years ago|reply
Producthunt seems more like feature hunt with the multiple launches (releases).
[+] ilrwbwrkhv|2 years ago|reply
Agreed. Product hunt climbers and what hackers like is mutually exclusive these days. As soon as I see product hunt badge I think oh it's for them...
[+] o-o-|2 years ago|reply
I'm in the middle of bootstrapping a SaaS company and spent the last few days evaluating e-mail providers. I think my requirements are really simple, yet I seem to fall outside what most offer. Here it goes:

* A user-friendly WYSIWYG template editor (web fonts = nice to have but not crucial). * An API that lets me set the to-address and the e-mail content in markdown.

How can this pose an edge case?!

[+] adamkaz|2 years ago|reply
As far as the fonts - font support across email clients is.... not great. We offer it but warn our users that their chosen font might not be displayed in most cases.

Ideally, you'd be able to paste any markdown into our editor and have it render properly, but still something we need to work on.

A markdown to HTML (email) converter would be neat though.

[+] hu3|2 years ago|reply
How would markdown play in this case?

I would expect API to parse JSON with variables to replace in the templates.

[+] mtmail|2 years ago|reply
My Firefox browser consumes 600% CPU browsing the homepage. Maybe an endless loop somewhere? I use adblock.
[+] robflaherty|2 years ago|reply
I see this with Framer sites all the time. Happens in Chrome too.
[+] chrisfrantz|2 years ago|reply
Oof don’t love that! I’ll test with FF later today.
[+] a-l-e-c|2 years ago|reply
One issue I usually see with these services is related to not being able to send out email campaigns with "dynamic content" pulled from the client's DB or APIs (based on specific user/list segmentations)

Had cases where the exact same campaign or template had to be created multiple times due to the client wanting a slightly different intro/closing or even entirely different products and services promoted based on user/account preferences.

Sure, it could be managed with multiple campaigns/templates/lists but these duplications could easily be avoided by using slightly more advanced "segmentation logic".

This is usually the case where tracking/stats aren't that important but rather making sure the user receives relevant content.

[+] chrisfrantz|2 years ago|reply
Sure, you can mostly do that today with saved segments, merge tags and data variables. Would love to understand how we could do better though!
[+] kylegalbraith|2 years ago|reply
We use Loops to power some of our email things for Depot [0] and Resend for other bits of it. In general, it's been a pleasure to use.

I think there are some logic things to get right at the API level, like should I use events or contact properties to trigger loops? We're working on some of that and wish the guidance was a bit better/clearer. At the moment, any properties you send with an event get added to the contact, so it seems like contact properties are the way to go.

My last request would be to support array properties on contacts, as a given contact could be in multiple "things".

[0] https://depot.dev/

[+] Multiplayer|2 years ago|reply
How does this contrast with sendgrid? We use their api and do not upload contacts to them.....
[+] nibab|2 years ago|reply
this is a layer on top of sendgrid. common functionality that a lot of users have to implement before any sendgrid api endpoint is invoked.