HN Explorer

Launch HN: Dittofeed (YC S22) – open-source customer engagement platform

135 points by maxthegeek1 ↗ HN
Hi HN - we’re Max and Chandler, and we’re building Dittofeed https://dittofeed.com. We make it easy for growth and marketing teams to message their customers across multiple channels. We're an open source alternative to platforms like Iterable, http://customer.io/, Braze, and OneSignal. Here’s a short demo video showing how to run the platform locally, and use it to automate a customer onboarding journey:

https://www.loom.com/share/0f7b67170b3a4205add00c22844ca06f

We created Dittofeed to tackle some commonly felt pains with customer engagement platforms:

First, existing platforms make it difficult to keep imported user data accurate and up to date with your primary user datastore. To solve this, we’re building first-class support for importing data from your data warehouse, for better data consistency.

Second, graphical “journey builders” are fragile, and difficult to debug at scale, so we’re building git-based workflows to check your messaging automation into git as configuration, as well the ability to run Dittofeed locally in development, or in CI with our testing sdk, for improved ease of debugging.

Third, companies in industries like finance and healthcare are often forced to implement their own solutions in-house to avoid sharing sensitive PII with third parties. As an open source platform, companies can now self-host us to keep their PII in their network.

Chandler, having worked in marketing for startups, experienced these challenges first hand. Max, on the other hand, was a senior platform infrastructure engineer at Braze, where he witnessed similar challenges from a technical perspective. Our combined experiences sparked the idea for Dittofeed.

We decided to create an open source, developer-focused customer engagement platform, because the often unspoken truth is that maximizing the effectiveness of these tools requires ongoing engineering involvement.

Dittofeed is built on Clickhouse (OLAP store used for storing user events, performing user segmentation, and aggregations) and Postgres (OLTP store for persisting application configuration, and serving user aggregations for efficient single-row reads).

If you can use the following, we’d love it if you checked us out:

Email support via sendgrid (other channels coming soon).

User data import via Segment integration.

We have a cloud offering, and offer paid support. You can find our pricing on our site https://dittofeed.com/pricing.

How to try Dittofeed out:

Check out our demo site to play around with the app https://demo.dittofeed.com/dashboard

Run the app locally via docker compose (https://docs.dittofeed.com/deployment/self-hosted/docker-com...).

Join our slack and we’ll set you up with cloud hosting (https://join.slack.com/t/dittofeed-community/shared_invite/z...)

We’d love to hear your thoughts, opinions, and experiences with these tools. What’s been your experience working with this kind of tech?

46 comments

[ 87.9 ms ] story [ 462 ms ] thread
aiunboxed
1. Does every user get their own clickhouse instance or is it shared ? 2. For email / sms which integrations do you support ?
maxthegeek1
It depends! If you're self-hosting you'll get your own clickhouse instance.

Our base cloud hosting currently uses a multi-tenant clickhouse instance, but we also optionally provide a single tenant instance as part of our enterprise cloud offering.

Currently we support sendgrid for email, and SMS is upcoming.

revskill
I don't see the auth for dashboard on github. Am i missing anything ?
maxthegeek1
We have authorization built into the app, but are using a simple auth proxy, with oidc for authentication. If you want to authenticate your own app, you can use something like ouath2-proxy with an oidc provider, and set the `AUTH_MODE` configuration in our app.

Happy to walk you through it if you join our slack.

eastbayjake
Very cool! Love seeing more JavaScript projects in the Marketing/eComm open source community, really neat value proposition for MarTech teams to be insanely productive with high-leverage full-stack JS developers
maxthegeek1
Thank you! Choosing typescript was intentional on our part, because we want growth / marketing engineers to feel comfortable contributing.
ilrwbwrkhv
Self-Host with Docker Compose. No thanks. I hope open source projects move away from Docker and move towards a single executable binary like PocketBase.
daxaxelrod
Curious why?
nonrepeating
Some people are annoyed with the way Docker (the company) has tried to monetize the technology by revoking free repos from open-source teams. If I recall, Docker doubled back on that.

Realistically, Docker is a fine choice for this.

ilrwbwrkhv
Not just that. I don't want to run 3 layers of operating systems to then run the program.
maxthegeek1
Offering a single executable binary is definitely great, but wouldn't be super practical given our choice of technologies. Tradeoffs.
singpolyma3
Nothing forces you to use Docker, it's just their documented happy path because it's popular.
slig
Do you want a single binary with Postgres/Clickhouse/Kafka built it? Because that's what their Docker Compose is setting up.
maxthegeek1
+1. Wanted to jump in to say that the kafka dependency is strictly optional. It's used to batch writes to clickhouse, but for less intensive workloads Dittofeed can use clickhouse's asynchronous inserts for in-memory batching.
daxaxelrod
In your demo I tried to create a message template but email go auto selected vs a "Choose your channel" flow that I expected. Cool tech though!
maxthegeek1
We're working on our second channel right now (mobile push), which will have the flow you'd expect when released. Thanks!
daxaxelrod
Neat, thanks!

Also something that irks me is that all these platforms design DAGs as journeys. Journeys are fine but they're inherently value capped. A user is only supposed to go through an onboarding journey once or a memorial day sale journey once.

What I really want as a mobile app dev is loops. I want to be able to say "Run this every day, send a user a push or email at 10am. wait until 6pm. if the user hasnt opened the app yet, send another push based on a different template".

Currently we have a whole ass subproject dedicated to defining these flows. whats worse is that its hard to ab test flow and impossible for anyone non technical to set up a loop. Please build this, we'll pay you sweet sweet MRR if you do.

maxthegeek1
Our plan is to model loops by having journeys define re-entry conditions, allowing users to run through journeys multiple times on a schedule. Would love to talk, to learn more about y'all are doing.

My email is: max@dittofeed.com, or feel free to ping me on our community slack!

zoogeny
On your pricing page, it just says $75 for cloud.

Is that per month? per year? one time purchase? Pardon me if it is described somewhere, but I've scanned the page multiple times and can't determine it.

chandlercraig
Thanks for that catch! Just edited. It's a monthly SaaS subscription.
paezand
Great stuff! Curious why you chose Clickhouse instead of other OLAPs like Druid or Pinot.
maxthegeek1
One of our motivations for selecting Clickhouse, is that it's relatively simple to run as a single node. This makes things easier for people who are looking to self-host a small to midsized installation of Dittofeed. It's also IMO a better developer experience for Dittofeed contributors who are running Clickhouse locally.

As far as functionality I'm a fan of Clickhouse's swappable table engines.

jacksparrow11
Amazing! Our team at Airbnb built something similar for internal users: https://medium.com/airbnb-engineering/journey-platform-a-low...

Very cool how we both use Temporal for workflow orchestration. Love the git idea, Wish you the best!

maxthegeek1
Thanks for the kind words :) Temporal is a great technology for this use case.

Wow, our DSL even looks similar!

Your app has beautiful design, which I guess shouldn't come as a surprise given that it's Airbnb.

Would love to chat to discuss further.

max@dittofeed.com

rubenfiszel
Hey Max (and jack), I'm actually curious on your feedback of using temporal for this use-case. I'm building an alternative to temporal (and a low-code builder to run arbitrary code on top) at windmill.dev and keen to learn on your experience. I will send you a DM.
sabr
Are you using Temporal Cloud?
maxthegeek1
Currently, we're just hosting temporal ourselves in our k8s cluster. However, I've been working with their team, and we'll likely be migrating our temporal cluster over to their cloud in the near term future.
Cshelton
Just checked out Temporal...

I don't know how I didn't know about it before..

I literally implemented a whole system to do what it does.

Thanks for bringing that up!

manibatra
Would love some docs on migrating from Customer.io. Looks really cool. Congrats on the launch!
maxthegeek1
Thanks! Definitely, migration guides are coming. In the meantime, feel free to ping us on our community slack and we'll walk you through a migration process.
anilgulecha
Do you also plan on submitting a caprover template? If you do, can ask my team to set it up in our instance.
maxthegeek1
Unfortunately, we don't plan on supporting caprover. We do plan on supporting render, and providing a helm chart in the near future.
kasra85
FWIW supporting CapRover is possible by just a docker compose file.
chevman
You guys have some intriguing ideas here.

I've been in this space for 15+ years now, worked with most of the main players that have on-prem and SaaS solutions, and deployed and run solutions at scale at a few of the largest companies in BigCo land for multiple years now.

I would be cautious on focusing too heavily on the 'developer as the customer' here. Most buying decisions in this space are not made by IT, they are made by CMOs, CXOs, CDOs, etc as that is who owns the budget (and results) tied to this type of solution.

At almost any scale, when you look at total cost of ownership, licensing from one of the main solution providers is usually quite a bit cheaper than building out a whole proprietary stack that one then has to maintain in house via their IT org that likely is not an expert at this kind of stuff.

maxthegeek1
Thank you, and you raise some great points.

Re-"developer as the customer", the mismatch between who makes the buying decisions for this kind of tech (CMO's etc.), and the devs who do much of the heavy lifting to make it work, is a real challenge.

Also, your point re the economies of scale of self-hosting vs using saas is valid. For small to mid sized orgs, using a cloud offering can be more economical.

However, we've observed that larger orgs often migrate off of saas to use open-source or build software in-house. This occurs for a number of reasons:

- They will have more engineering resources to allocate, in this case to marketing / growth.

- At their scale, the fixed costs of allocating engineers to implementing solutions are often exceeded by the variable costs of saas products, which commonly have volume based pricing.

- They often have more unique requirements that are not served by any particular saas product, and closed source saas is not extensible.

Some recent examples of this:

- Several large orgs are migrating off datadog in favor of open source observability tooling.

- Airbnb recently implemented the equivalent of Dittofeed internally (they responded in this thread).

Still, you raise legitimate concerns, and we're still figuring things out. Would love to get in touch, to better understand your perspective if you have time!

tailspin2019
Maybe I’m reading too much into your comment, but it seems like an overly negative/cautious take?

Personally I can see exactly where this product fits in and provides a valuable alternative to the incumbents, and I’m really happy to see a self-hosted open source solution in this space.

The ability to have total ownership and control of the customer data (when needed) is great.

The balance between a friendly UI and a well thought out developer/integration experience seems especially good to me.

The TCO is going to vary wildly based on the org’s scale and state of development. And yes, skillset. Your reservations might be slightly skewed by your experience in “BigCo” land? :)

soumyadeb
What you are saying is true but wonder if that's how it should be?

Marketing (via email, push, ad, whatever channel) should be an extension of their product experience and it can be owned by the product/engineering team. I have seen instances where growth-marketing reports to prod/eng.

Makes sense to have more right-brain activities (brand marketing, ads etc) to not come under engineering but growth marketing is often very analytical.

kfk
I think for Enterprise you should include professional services and consulting in TCO. And usually the Enterprise SaaS tools you mention are a bit cheaper on licenses, but very expensive on the consulting. It makes sense because if a tool is open source and known there is a lot more talent in the job market, if a tool is closed source it takes money just to learn it and people have to recover that investment.

But you are right, I think Dittofeed should sell their benefits to C-Suite execs, not to developers.

Onavo
Thoughts on Laudspeaker?

https://news.ycombinator.com/item?id=34835559?

abe94
One of the founders / maintainers of Laudspeaker [1] here! We think its great that there are more open source options in the space and really nice design guys!

Some differences:

a) We have explicitly decided against a DAG approach [2] for our visual editor and use state machines as our model, so you can explicitly create things like loops, and customize journey logic more.

b) Our cloud pricing is not user based, but right now follows a pay as you go model for usage with sliding discounts for larger message volumes [3]. While the mechanics may change we are most likely going to avoid user based pricing models.

c) We support different channels at the moment (email, sms, firebase push, slack, in app modals) and we integrate with databases/ warehouses as well as product analytics services like posthog [4] and CDPs like rudderstack. I'm sure with time we will converge on the same channels/integrations.

d) We think journey versioning / testing is a great idea, and don't yet have that but are rolling out our own.

Some similarities:

a) We also use clickhouse, and at some point will use temporal (our project is supported by one of their executives)

b) We also have a visual editor, segments and templates

c) We can be self-hosted (A few users are self hosting today)

For others checking this out there are also older projects like Mautic [5]. And customer engagement is a large enough category that it includes projects like Chatwoot [6] that focuses more on customer support.

[1] https://github.com/laudspeaker/laudspeaker

[2] https://laudspeaker.com/docs/engineering-blog/finite-state-m...

[3] https://laudspeaker.com/pricing

[4] https://posthog.com/tutorials/laudspeaker-posthog

[5] https://www.mautic.org/

[6] https://www.chatwoot.com/

maxthegeek1
It's honestly gratifying to see that we landed on a similar product space independently. I read it as a strong signal that there's a real need for the product. I've been impressed by how much ground they've been able to cover, and how quickly they're building.

Beyond that, I think our focuses are somewhat different, as our current roadmap is focused on serving growth engineers. Still happy to see them working in the space.

kylegalbraith
Congrats on the launch and the progress. When folks want to self-host your offering, do they want to be able to run your offering on things other than Intel CPUs? I noticed that you only build an image for Intel and not for Arm.
maxthegeek1
Great question. Hasn't been requested yet, but I'm sure we'll need to support arm at some point.