121–130 of 141 posts
This looks like a really nice and polished product, I am in the same space, I've been working for a while on a similar project, pretty much feature parity but with one caveat, it's pay-once and use forever (1 year of free updates), self-hosted, no dependencies, one binary. I'll be keeping a closed eye to you guys, it's pretty much what I wanted when I started my project.
Isn't 98% of email about having a clean IP range these days?
My Firefox browser consumes 600% CPU browsing the homepage. Maybe an endless loop somewhere? I use adblock.
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)
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...
They're targeting SaaS and SaaS means traditionally a signup is needed to be a customer which turns into a contact.
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".
Earlier quoted context omitted.
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.
Potential SaaS customers register trial accounts all the time. Do each address count as a new contact even though they only receive, say, an activation email once and never come back?
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 considerin…
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…