[HN Gopher] Show HN: I made a MailChimp alternative that connect...
___________________________________________________________________
Show HN: I made a MailChimp alternative that connects to your
database
Hi all! Excited to share cc.dev after months of work and
refinement. 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): https://cc.dev 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
Author : kashnote
Score : 160 points
Date : 2023-07-23 16:03 UTC (6 hours ago)
(HTM) web link (cc.dev)
(TXT) w3m dump (cc.dev)
| iamacyborg wrote:
| Nice to see another entrant in this space, there are still very
| few platforms that allow you to do this and it's, IMO, a real
| differentiator.
| sails wrote:
| > 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.
|
| 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.
| iamacyborg wrote:
| There can be a lot of complexities in syncing a user model into
| an email platform if it doesn't match your business model.
| elliotkillick wrote:
| This looks like an interesting take on email marketing. I use an
| open source solution called Listmonk (w/ Amazon SES) for my
| emailing needs. How does this project compare?
| addisonj wrote:
| Congrats on the launch!
|
| 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 :)
| kashnote wrote:
| Amazing points, thanks so much! Totally agree with you on the
| docs. I'll definitely look into creating some sort of agent (or
| some other solution), but I agree that some docs explaining
| everything will ease the minds of those who are on the fence.
|
| Hm interesting point on the open sourcing and monetization.
| I've been thinking a lot about this and still not sure if it's
| wise to open source it. I definitely want to generate revenue
| from this. Perhaps going open source would be detrimental to
| that.
| addisonj wrote:
| I should say... Open source _can_ be a great way to get a
| community of users, with a subset that will opt not to self-
| host, but, I think there are a lot of things to consider:
|
| * Can you shepherd a community, that will have issues with
| self-hosting, prs, bugs, etc AND do all the stuff needed to
| run a company (once again, assuming one person show here)
|
| * By going open source, you now are also "competing" with
| other OSS projects, which may drive toward features that
| don't drive value on commercial side. You may also find that
| the core value prop just doesn't translate well to open
| source, for example, if the target is JAMstack teams and you
| can't run this on vercel, cloudflare, fly, etc
|
| * I think the most successful open projects like this tend to
| be something that is a segment _only_ really solved by
| proprietary companies. For example, workflow automation like
| Zapier built a novel model and led to open source with hosted
| version projects like n8n to replicate that, with many people
| offering that as a service inside their company. I think
| "open source MailChimp" isn't a bad play, but I don't know if
| that is really what you are doing, so it is hard to say if
| open sourcing would led to sales or to useful software that
| no one wants to pay for
| ttul wrote:
| If you send through Cloudflare Workers using MailChannels, the
| sending is free with no cap.
| kashnote wrote:
| Woah cool! I actually hadn't heard of this. Would be cool if I
| can integrate this into the platform. Been thinking of adding
| other backends like Sendgrid and Resend.
| zenorocha wrote:
| Resend founder here - let's make it happen
| c0brac0bra wrote:
| Haven't heard of resend before. I've been pretty unhappy
| with Sendgrid, especially their usability when running lots
| of subaccounts.
|
| Since you're here, how would you say you compare vs them or
| say sparkpost? I looked for comparisons on your site but I
| wasn't able to find anything.
| ttul wrote:
| The ideal way to accomplish this would be to get your
| customers to install a tiny proxy Worker in their own account
| and then just connect your service to it.
|
| https://support.mailchannels.com/hc/en-
| us/articles/456589835...
| ibpasha1 wrote:
| Awesome. Love the concept!
| voidbound wrote:
| Very clean! I'll definitely try it out
| sergiotapia wrote:
| If I have SES and MJML and the SQL query - why not just run this
| on my app server? Why pay you to hit the SES API with my markup?
|
| I don't quite get it.
| sakopov wrote:
| Major problem with this is that your customers should ideally
| never expose their databases for public access.
| xp84 wrote:
| Devils advocate here: if you created a database user, which has
| access to a single View of with email, name, and whatever
| relevant subscription properties, how is that functionally
| different than what everyone does today which is to set up some
| Rube Goldberg contraption to pipe that audience information to
| mailchimp, sendgrid, or exacttarget?
|
| Personally, I find this really intriguing and think it would be
| much better for data security because it would be far less
| likely that they will have my customers' email addresses lying
| around their database months or years after I cancelled the
| service.
| failTide wrote:
| you'd still be exposing the database system itself to the
| public regardless of the credentials you were using for the
| email service, as opposed to keeping it all within a VPC
| which seems to be what most guides recommend.
|
| I assume the difference would be that having your database
| exposed presents additional surface area for attacks. A rube-
| goldberg style setup probably presents its own risks, but
| personally I just use AWS SES for my transactional/marketing
| emails and it's a one-way pipe that doesn't present any
| significant risks as far as I can see.
| 8organicbits wrote:
| Using a public facing database, but using an IP address
| allow-list to restrict access is pretty secure. cc should
| publish the IP addresses they use.
| kashnote wrote:
| It's listed on the Data page! No need to open the
| database up to the whole internet. Just whitelist one IP.
| sakopov wrote:
| Doesn't matter. The database still is on a public subnet
| on customer's network. All it takes is for someone to
| jack up some kind of white list or access rule and the
| entire database is exposed. It's an attack vector. You
| can't do this nearly as easily when the database is in a
| private subnet w/ no access to internet.
| scrose wrote:
| I mostly agree, but do want to emphasize that it really
| depends and there are multiple ways to secure this that
| range in complexity and maintenance overhead.
|
| The top thing that comes to mind is creating a separate
| 'read replica' DB that logically replicates target
| table(s) from the source DB, creates a materialized view
| with a subset of the replicated data in the replica db,
| and then exposes only the materialized view to a specific
| 3rd party user.
|
| That way you:
|
| 1) Run your primary db in a private subnet -- addressing
| your concern with ip whitelisting
|
| 2) Run the replica in a public subnet with extremely
| limited access(ip-whitelisting and limited access
| controls to data).
|
| This is definitely a more complex setup to reason about
| and creates more moving parts that can fall out of sync,
| but it does greatly decrease the blast radius of a
| breach, and for some orgs, that may be a worthwhile
| trade-off. In my opinion, the OP would probably benefit
| from some basic security walkthroughs on these different
| implementations to help engineering teams get
| onboarded/make a better case for their solution if they
| hit friction with legal or security teams.
| TZubiri wrote:
| Right. It reminds me of SetVar and GetVar as a solution to
| exposing state
| constantly wrote:
| This does seem cool. When the service matures, are you going to
| eventually move it to production?
| kashnote wrote:
| The service is technically ready for use and I've already sent
| several thousand emails with it, but I have the Beta tag on
| there for now just to tell people that it's new and to reach
| out if they want to chat about their specific use cases before
| proceeding.
| neom wrote:
| How do you manage reputation?
| kashnote wrote:
| Emails are sent using your own AWS SES account, which will
| handle all of that. No real concern of people sending spam
| because they would be damaging their own SES reputation.
| neom wrote:
| Well that's not a MailChimp alternative my friend. That's a
| wrapper around SNS, there's a reason those of us in marketing
| wouldn't accept this.
|
| I don't even like MailChimp but there's a real reason to use
| an app like them/similar. They help you not screw up "all of
| that" is complicated.
| TZubiri wrote:
| And mailchimp is a wrapper of other tech, but it's still
| its own thing.
| primitivesuave wrote:
| This is only true if you are using dedicated IPs with SES
| (~$30/month each). However, SES is pretty good at managing IP
| reputation even for the shared IP service, and I haven't had
| any issues in over 10 years of building systems on top of it.
| sandGorgon wrote:
| the biggest challenge to fix is the double opt-in and opt-outs.
| CANSPAM and lots of other regulations make it tricky to not do
| this well. And if u start getting marked as spam, then SES will
| ban you.
|
| 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...
| carlossouza wrote:
| I think there are some good ideas here, but the target audience
| imho is not clear.
|
| 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".
| paulcole wrote:
| > The greatest thing about the idea is "email marketing
| cheaper".
|
| Welcome to customer service hell.
|
| And the inevitable competitor who will do it cheaper. If all
| that differentiates you is low price, good luck.
| kashnote wrote:
| The target market is someone who
|
| 1. is tech-savvy and runs an app/service with a bunch of users
|
| 2. has tried existing emailing platforms and feel that they're
| too expensive
|
| 3. wants full freedom of who they target their emails to
|
| A tech-savvy person _could_ make their own solution, and that
| 's what I wanted to do with my site CubeDesk, but it's
| surprisingly difficult and time-consuming, which gave me the
| idea for this service.
|
| The English -> SQL thing is just a fun feature I added since
| I'm excited about LLMs. Comes in handy for folks who aren't SQL
| experts (like me).
|
| Totally agree on the security concerns. That seems to be the
| main feedback in this thread and will be my main focus going
| forward!
| xmprt wrote:
| I, for the record, find this pretty interesting and am
| exactly in the target audience for this (down to the cubing
| part. Maybe I'll see you at a WCA comp sometime). I might
| check it out sometime. I do wish there was some kind of self
| hosted option though. Or a way to do this without linking any
| AWS credentials or database passwords.
| jacobsimon wrote:
| Been wanting something like this for years over at Exponent.
| We do a lot of targeted and dynamic emails to our users based
| on their role and progress through our courses, and it's a
| pain to not only synchronize the database with the mail
| provider, but to agree on a system for capturing the state of
| the user that works with the platform - we've ended up
| creating a complex system of tags that has to be maintained
| across both systems.
|
| Re: non technical users, one idea would be an ability to save
| "audiences" using smaller SQL queries, that way non-technical
| collaborators could easily send a campaign to a well-defined
| group of users, and update the group definition once instead
| of across all your emails.
|
| If you could infer the structure of the connected database
| automatically and control which tables are visible in the
| product, people might find that really helpful too (check out
| Metabase as an example product that does a great job at
| querying data sources with UI and raw SQL)
| deepspace wrote:
| Sendy (https://sendy.co/) ticks all those boxes, plus it is
| self-hosted, so I don't need to share my database with
| anyone.
| dangus wrote:
| My first thought when I read this post was "did you try
| someone besides MailChimp?" My understanding is that they're
| not really a market leader and that there are competing
| solutions that are either better, cheaper, or both.
|
| That said I think this is an interesting niche to be in,
| because I think there are some customers out there who don't
| need the technical hand-holding of other marketing platforms.
| jroesner wrote:
| How do you define market leader? In 2021 they had 14
| million paying customers and a market share of 72 percent.
| If that's not a market leading position, I don't know what
| is. I don't favor them, it's a real pain sometimes, but
| they operate a tanker, not a speed boat.
| imafish wrote:
| Also target audience here. I second the views of sibling
| post.
| jonathanbull wrote:
| The market for entrepreneurs/companies who know how to create
| IAM credentials but _don 't have the time or skills to build an
| entire email marketing platform on top of Amazon SES_ is bigger
| than you think (I co-founded EmailOctopus which does the same
| thing without the database hookup, which is a cool idea).
|
| Good luck with it @kashnote
| kashnote wrote:
| EmailOctopus looks really nice! If I have a fraction of the
| success you guys seem to have, I'd be very happy haha
| carlossouza wrote:
| I'll update my beliefs after your data point :)
|
| Congrats on EmailOctopus; it looks like a nice product!
| doylemark wrote:
| How does this connect to the database? Does an agent have to run
| within your VPC?
| tln wrote:
| This looks great! Sounds like you track events like opens, clicks
| SES features.. does that mean you need a specific table in my
| database?
|
| What data about my users would be stored in your database, vs my
| database?
| kashnote wrote:
| I haven't added link tracking yet, but it's on my list. To be
| honest, I'm hesitant to add open tracking because it always
| felt a bit creepy to me and also plenty of email clients are
| blocking them nowadays, so they're becoming useless.
|
| As for the data question, when you create a campaign, the
| following gets stored for each email that will get sent:
|
| - email address - JSON blob of the required variables that
| exist in the subject and body of the email (ex: {first_name:
| "John"}
|
| That's pretty much all the data that will be stored in our
| database which is sourced from your database. This data is
| stored for 30 days then removed, but I'd like to make this be
| configurable.
| georyb wrote:
| Needs some sort of webhook / API access through your dashboard.
|
| I'd be interested in running a cronjob with my custom SQL and
| sending you a batch payload to process the emails.
| rcme wrote:
| This is a really cool idea. Do you do any management of
| subscription status so that users can unsubscribe from emails?
| That would be really useful.
| kashnote wrote:
| Yup! On the Data page there's an Unsubscribed list where you
| can import unsubbed emails. And you can include [[unsubscribe]]
| anywhere in an email template and that will be replaced with an
| unsubscribe link which the user can click.
| zxcvbn4038 wrote:
| Having your database exposed on the public internet so a third
| party service like this can read it directly is a very bad idea
| IMO. I get what your going for but the end here is some mom and
| pop getting their database compromised.
| CableNinja wrote:
| I see a lot of security concerns with this.
|
| 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.
| wohlgejm wrote:
| Another issue is that the data needed by this application is
| going to be sensitive - email addresses, names, etc. Many
| applications will encrypt these values with application logic.
| So a database function will need to perform it. The encryption
| key is going to be need to written into the query in this app
| if that works, adding more surface area to where that key
| lives. That's also assuming the simple use case of a single
| key, not per tenant, or roating, etc.
| CableNigger wrote:
| [dead]
| kashnote wrote:
| Very legitimate concern and one I've been thinking about a lot.
| Honestly, I think the best way to address this is to just go
| open source, which I'm totally open to. I think once I've
| validated the idea a bit and know it's something people are
| interested in, I'll focus on this issue and come up with a
| solution (whether it's open sourcing or something else)
| blopker wrote:
| I was super excited when this popped up because I'm looking
| into solutions for this problem right now. I was, however,
| surprised to see it wasn't self-hosted or open source.
|
| As others have mentioned, there are security issues here that
| would be a non-starter for me. Even just having to open a
| database to the open internet for an external service to
| connect to is too much, even if I trusted that service
| completely.
|
| Self-hosted fixes these issues since outbound traffic can be
| locked down so only connections to SES are allowed, and no
| databases have to be exposed to the internet.
|
| However, many people will also not want more than 1 service
| talking directly to a database for a few reasons:
|
| 1. Databases are often a single point of failure. A bad query
| can take down a whole service. Allowing queries that don't
| pass code review can be dangerous here, even if it's locked
| down to be read-only. This can be mitigated by talking to
| replica databases, but that's more setup.
|
| 2. Migrations on data that is accessed directly from multiple
| services becomes harder. Many server frameworks handle data
| migrations, and they assume ownership of the data. These
| frameworks cannot account for other services and cannot make
| sure the queries will continue to work. This is less of an
| issue if the query is a one-off though.
|
| 3. Having multiple services talk directly to a database
| pushes all the security, data validation and processing to
| the database. Many developers (myself included) prefer to
| keep database configuration as simple as possible since they
| are already complex.
|
| Anyway, sorry for the long post, but I thought my experience
| might be useful in developing this! Generally, I'd love to
| see a simple, self-hosted MailChimp. Especially one where I
| could keep all the configuration in version control.
| CableNinja wrote:
| Going open source will not solve your problems. The issue is
| that youre asking customers to open database access to
| you/your company. The reason why the method youve chosen isnt
| already out there is because of all the implications it has.
|
| You better have one hell of a security team to ensure youre
| locked down tighter than a ducks ass. Look at how many data
| breaches there have been, even in the past year.
|
| The solution is to either make an SDK or API as already
| suggested by others, and giving customers endpoints to manage
| their lists.
| samstave wrote:
| A self hosted AMI/container - with a config UX. Simple
| solve.
| kashnote wrote:
| Definitely taking all the security measures I can, but
| you're right, things can go wrong. I do encourage (and
| would like to enforce) that db credentials provided should
| have very limited read access to only the tables/columns
| that the user wants to query.
|
| Having said that, it's totally understandable that some
| orgs won't want do open up their db. The idea with going
| open source would be that they can host the platform in
| their VPC so that their data is never leaving the premises.
|
| Not against having an SDK or API at all, but I would need
| to think about would work because the whole syncing issue
| is one that I'm focused on addressing here.
| Exuma wrote:
| I'm not a security expert, but at the very least if I
| were you make your docs very good for people who dont
| want to wade through 1000 different documentation to find
| how to very simply create a read-only user with access to
| specific table + columns. Or better yet even, how to
| create a read only view with ONLY the email/name and not
| any other PII, and then give access to that.
| CableNinja wrote:
| You dont need to go open source to allow self hosting,
| and, youll likely lose money that way. Its entirely
| possible to allow self hosting without being open source.
| Plenty of other projects do it.
|
| That being said, self hosting doesnt solve all issues.
|
| You, and whoever uses this product, will need MANY IPs
| because of blacklisting and throttling limits applied
| almost worldwide to all mail servers. Theres a reason why
| the marketing spam hosts have their own /24 or /25 and
| have 80% of them cycling through usage as a mail sender.
|
| Im not knocking your want to have something better than
| MailChimp and the like, but i feel like you didnt really
| dig into the real underlying tech and security before you
| went to work on this.
| tln wrote:
| You realize that the sending is done by Amazon SES right?
| CableNinja wrote:
| I did not.
|
| At that point id just configure SES outright and not even
| use this solution. Most other services use direct mailing
| from their own servers
| shusson wrote:
| Yeah what's the hesitation for having an API?
| sosborn wrote:
| I think even more interesting is that they chose to forgo the
| rather robust and easy to use API offered by Mailchimp in the
| first place.
| iamacyborg wrote:
| Mailchimp have already exposed customer user data.
| Controlling the integration in this way is likely more
| secure, not less.
| ivanvanderbyl wrote:
| Agreed. This makes me incredibly uncomfortable. I'd rather a
| simple SDK that pushes the contact details to their API.
| kundi wrote:
| What type of tracking does it provide? Open tracking and split-
| tests and stats would be essential for this to stand on a more
| solid group beyond hacking own scripts
| themanmaran wrote:
| Hey this is awesome! I got started on an MVP[1] of this earlier
| this year, but gave up simply because of all the additional mail
| features required to get this to a full product.
|
| 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.
|
| [1] https://github.com/tylermaran/pigeon
| [deleted]
| addajones wrote:
| great work! Useful option!! 250,000 emails at $44/mo (including
| SES fee).
|
| 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.
| vcryan wrote:
| The audience for this is so technical, that they just build this
| functionality themselves into their own app :)
| nickstinemates wrote:
| Homepage is beautiful. Product is clear. Very nice.
| tansan wrote:
| This feels like a very small step up from just doing everything
| in my codebase.
|
| 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.
___________________________________________________________________
(page generated 2023-07-23 23:00 UTC)