by kashnote on 7/23/23, 4:03 PM with 101 comments
The idea for this product came from trying to do email marketing for my side project, CubeDesk, a site where Rubik's Cube enthusiasts can time themselves, race with one another, train algorithms — it's a fun niche!
With over 40k users, sending even a single campaign was becoming expensive with MailChimp. I knew AWS SES would be much cheaper, but it’s just an API with none of the other necessities you need for a robust email marketing platform.
Beyond cost, I was also frustrated with having to make sure my database was always in sync with MailChimp and the audience schema they enforced. If I wanted to email every user who had completed 10 solves, that would be a whole ordeal and eat up hours of my day.
So, I started (and am now launching):
cc.dev connects directly to your database and lets you write SQL queries to target your audience. It's backed by AWS SES, so the cost to send emails is significantly less than what you're used to seeing. Combined with a template builder, media management, and campaign monitoring, cc.dev is meant to be your final destination whenever you need to send marketing emails to your users.
Would love to hear your feedback on this! If you're interested in trying out cc.dev as your email marketing platform, shoot me an email and let's have a chat: kash at cc.dev
by carlossouza on 7/23/23, 5:00 PM
Email marketing cheaper is a great attention grabber: kudos for the good copywriting.
Step 1: Link to AWS SES... humm, for that your target audience must be tech-savvy.
Step 2: Query your database... humm, linking my database to a strange system? No freaking way! But assume for an instant that this would be ok. For this, your target audience again must be tech-savvy.
Step 3: Create an email template using MJML... again, for tech-savvy people, not for the average digital marketeer...
Step 4: Review and send... ok, pretty basic..
English -> SQL. Here you got me confused. For steps 1, 2 and 3, your audience must be tech-savvy. This feature doesn't make any sense for tech-savvy people. It only makes sense for the average marketeer in a small team (or solopreneur) who doesn't know SQL. But this guy would never get through steps 1, 2 and 3!
See my point?
A tech-savvy person in a tight budget would develop his own solution. Imho, not your target.
An average digital marketeer or solopreneur who doesn't know how to code and is in a tight budget could be your audience. But for that, steps 1-3 must be no-code/for dummies.
The greatest thing about the idea is "email marketing cheaper".
by nlh on 7/24/23, 12:37 AM
1) I too am exactly in your target audience and I'm psyched to check this out (I'm the solo tech operator of an ecom business and this will exactly scratch an itch I have)
2) I'll echo what I wrote in another comment: It is VERY HN to get concerned about exposing databases, and folks who are posting about the security concerns are not wrong, per se, but also, you are going down a path that many other SaaS apps have successfully gone down, and it's a feature users want and will pay for. So while you should absolutely make sure this is done properly and advise your users not just to expose their databases willy-nilly, don't get psyched out by folks telling you it's a hard no to have to connect a DB directly. Users want this, will pay for it, and you're wise for doing it.
by sakopov on 7/23/23, 4:56 PM
by tansan on 7/23/23, 5:11 PM
My SES is already setup. I have templating for emails already. I can query my DB using my ORM without grant additional access. I guess I get the benefits of your UI for monitoring.
I'm really not sure if the net positive is large enough for me to consider the solution.
by CableNinja on 7/23/23, 4:22 PM
Many, if not all databases are not public accessible, nor should they ever be. Asking people to open their database up to you, sketchy and dangerous.
by ttul on 7/23/23, 4:32 PM
by danpalmer on 7/24/23, 10:33 AM
However. I don't think we'd have paid for this as a SaaS service. These sorts of tools could be engineering or marketing led. We had some marketing-led tools that were fairly hands-off from engineering, but they didn't connect to our database. We happily paid for these services. However this would have been engineering led, and we'd have wanted to self-host given how it worked.
Just my 2c, but I'd either keep it engineering-targeted, open source it, and make money on support, or change tack a bit to target at the marketing folks.
And a feature request: "linting" emails. We ended up with manual checklists for things like: do all the links resolve, do they have tracking tokens, is the plaintext preview good, is there an unsubscribe link. Linting for these would be a great productivity boost.
by zxcvbn4038 on 7/23/23, 7:05 PM
by edmundsauto on 7/24/23, 3:28 AM
During that time, they would have configured things and probably sent a few emails successfully. Just enough to have told their boss and gotten kudos.
by addajones on 7/23/23, 6:46 PM
Currently paying $25 to send 250,000 emails with sendy.co for years. Also using Amazon SES. no monthly fees just pay for what you use plus one time cost of sendy.
by neom on 7/23/23, 5:43 PM
by lxe on 7/24/23, 1:06 AM
Don't listen to the haters -- this is exactly what many of use were looking for.
Now only if you had better priced plans for smaller volumes...
by themanmaran on 7/23/23, 4:44 PM
Especially in startups, this is super annoying process. Say I want to test out a feature with 100 random users who have done XYZ before. Right now I have to do a SQL query, export that to a CSV, import to MailChimp, send.
by bbx on 7/24/23, 2:24 PM
The "Send 37 emails" button which triggers an animation is a nice touch. Foreshadows the actual experience.
by iamacyborg on 7/23/23, 5:13 PM
by sails on 7/23/23, 4:50 PM
Could you explain why this was such a problem?
It would seem like this (API to submit data) is the sensible way to balance the cost against the security concerns raised in the other comment.
Does mean engineering and sync issues which your solution does address in an interesting way.
by tough on 7/23/23, 11:17 PM
I've both tried ListMonk and Bespoke but both lack on features I might need.
Might just roll my own at this point lmao
https://github.com/knadh/listmonk https://listmonk.app
https://bespoke.surf/ https://github.com/bespoke-surf/bespoke
The aspect most important for me regarding this as an european based company is to be GDPR compilant so opt-in storing ip address and datetime is required by law.
What /i try to convey by this is that sending emails might be easy, but all the work around doing so lawfully is painfully burecractically comically hard.
by jamesfisher on 7/24/23, 12:07 PM
by mythz on 7/24/23, 6:19 AM
by vcryan on 7/23/23, 6:47 PM
by KomoD on 7/25/23, 3:40 PM
You could always move to Brevo (formerly sendinblue) or Mailjet, it'd be cheap.
If you're sending 40k emails/mo it'd be €29-38 or €45 at Mailjet(50k)
by constantly on 7/23/23, 4:56 PM
by sandGorgon on 7/23/23, 6:34 PM
this stuff is so critical that people will not use anything other than mailchimp. if you want to disrupt this space...disrupt this part of the product.
second biggest feature - support for Liquid templates. https://dripemailtemplates.com/tutorials/liquid-templates-gu...
by tln on 7/23/23, 5:02 PM
What data about my users would be stored in your database, vs my database?
by elliotkillick on 7/23/23, 9:50 PM
by georyb on 7/23/23, 6:40 PM
I'd be interested in running a cronjob with my custom SQL and sending you a batch payload to process the emails.
by kundi on 7/23/23, 8:15 PM
by rcme on 7/23/23, 4:20 PM
by sergiotapia on 7/23/23, 8:04 PM
I don't quite get it.
by nickstinemates on 7/23/23, 4:48 PM
by RyanShook on 7/24/23, 3:35 AM
by doylemark on 7/23/23, 9:33 PM
by ibpasha1 on 7/23/23, 4:53 PM
by ygouzerh on 7/24/23, 9:39 AM
by technologydaily on 7/24/23, 6:53 AM
by voidbound on 7/23/23, 6:04 PM
by addisonj on 7/23/23, 6:03 PM
Lots of really good stuff going on here, a few bits of feedback, ideas, etc, and also responding to some of the comments in other threads.
* The quick explanation of how this works is pretty strong, but I think the differentiator/value over other services maybe isn't called out as well. To me, this seems pretty clearly ideal for smaller teams all in on JAMstack/serverless with a lean stack that don't/won't have an easy place to create an automated process for synchronization, and are more likely to be using a planetscale/supabase/neon where this model is more attractive. I would suggest adding some of that info, not only to help target customers better recognize the value prop, but also help discovery via SEO.
* While the landing page gives a good overview, as a dev, before I sign up, I want more details of how it works, more complete examples, etc. For SaaS apps targeting the general market, after landing/product pages,the most visited pages are generally use cases, success stories, industry specific info, etc. But from my experience and talking with many others, for dev audience, docs are the next thing people visit (if they aren't ready to sign up). You don't need every doc at once, but things like a quick start guide, concept overview, feature overview, etc can all be high value docs that you generally need anyways for your first customers
* With docs, you can better address and explain the security side of things. I would do less on the landing page in regards to security and push that to more in depth detail in the docs. Talk about best practices of creating a read-only user. Create guides for most popular db vendors, etc
* As has already been mentioned, you will get concerns about any access to the db and "why not an API". I think these commenters are right that this will be a deal breaker for many companies, but I don't agree that you want an API. Not only because I think that reduces some of the value prop but also because then you would need to store customer data. I obviously don't know what you are storing today, but I would think that this model could have a big advantage if you didn't need to store any PII data in cc.dev. The complexity of dealing with compliance and regulatory requirements is no small part of why something like MailChimp is expensive is that burden. I don't know if this is something you currently consider a value prop (or if you have engineered to support this)... But I certainly would :)
* To address the reality of private dbs/giving access to a db, I would look at potentially implementing an agent. This agent would then run the queries (still provided by the user) and just-in-time deliver the results when needed. Getting the model of this right that works across different companies view of security will mean this is probably best to do with a handful of potential customers.
* As far as deployment and monetization model... I would only open source it if you are giving up on commercialization or if you can open source a subset that can be useful enough to build a community. Once again, returning to JAMstack, maybe solve in open source (but integrate) some problem unique to those teams. As far as a paid self-hosting, given that this seems like a one man show, I would resist it. Trying to do SaaS and support of self-hosting is rough, even for well funded VC backed teams..
Quite a bit here, but if you want follows up on anything, my email is in profile or will reply to comments.
Congrats again and hope it goes somewhere :)