[HN Gopher] Launch HN: Dittofeed (YC S22) - open-source customer...
___________________________________________________________________
Launch HN: Dittofeed (YC S22) - open-source customer engagement
platform
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?
Author : maxthegeek1
Score : 127 points
Date : 2023-05-24 17:24 UTC (1 days ago)
| daxaxelrod wrote:
| 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 wrote:
| We're working on our second channel right now (mobile push),
| which will have the flow you'd expect when released. Thanks!
| daxaxelrod wrote:
| 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 wrote:
| 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!
| michaefe wrote:
| This looks great!
| eastbayjake wrote:
| 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 wrote:
| Thank you! Choosing typescript was intentional on our part,
| because we want growth / marketing engineers to feel
| comfortable contributing.
| zoogeny wrote:
| 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 wrote:
| Thanks for that catch! Just edited. It's a monthly SaaS
| subscription.
| chevman wrote:
| 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 wrote:
| 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!
| kfk wrote:
| 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.
| soumyadeb wrote:
| 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.
| tailspin2019 wrote:
| 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? :)
| jacksparrow11 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| maxthegeek1 wrote:
| Great!
| sabr wrote:
| Are you using Temporal Cloud?
| maxthegeek1 wrote:
| 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 wrote:
| 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!
| paezand wrote:
| Great stuff! Curious why you chose Clickhouse instead of other
| OLAPs like Druid or Pinot.
| maxthegeek1 wrote:
| 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.
| kylegalbraith wrote:
| 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 wrote:
| Great question. Hasn't been requested yet, but I'm sure we'll
| need to support arm at some point.
| aiunboxed wrote:
| 1. Does every user get their own clickhouse instance or is it
| shared ? 2. For email / sms which integrations do you support ?
| maxthegeek1 wrote:
| 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 wrote:
| I don't see the auth for dashboard on github. Am i missing
| anything ?
| maxthegeek1 wrote:
| 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.
| manibatra wrote:
| Would love some docs on migrating from Customer.io. Looks really
| cool. Congrats on the launch!
| maxthegeek1 wrote:
| 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 wrote:
| Do you also plan on submitting a caprover template? If you
| do, can ask my team to set it up in our instance.
| maxthegeek1 wrote:
| Unfortunately, we don't plan on supporting caprover. We do
| plan on supporting render, and providing a helm chart in
| the near future.
| ilrwbwrkhv wrote:
| 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.
| singpolyma3 wrote:
| Nothing forces you to use Docker, it's just their documented
| happy path because it's popular.
| slig wrote:
| Do you want a single binary with Postgres/Clickhouse/Kafka
| built it? Because that's what their Docker Compose is setting
| up.
| maxthegeek1 wrote:
| +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.
| maxthegeek1 wrote:
| Offering a single executable binary is definitely great, but
| wouldn't be super practical given our choice of technologies.
| Tradeoffs.
| daxaxelrod wrote:
| Curious why?
| nonrepeating wrote:
| 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 wrote:
| Not just that. I don't want to run 3 layers of operating
| systems to then run the program.
| Onavo wrote:
| Thoughts on Laudspeaker?
|
| https://news.ycombinator.com/item?id=34835559?
| abe94 wrote:
| 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 wrote:
| 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.
| mikaeln wrote:
| Congrats on the launch!
___________________________________________________________________
(page generated 2023-05-25 23:02 UTC)