[HN Gopher] Launch HN: Papercups (YC S20) - Open-Core Intercom A...
___________________________________________________________________
Launch HN: Papercups (YC S20) - Open-Core Intercom Alternative
Hi HN! Kam and Alex here. We're founders of Papercups
(https://papercups.io), a live customer chat app written in Elixir.
We offer an open-core self-hosted alternative to Intercom for
companies that are security and privacy conscientious. Alex and I
met in SF around 6 years ago, and have been hacking on small
projects together for the past couple years. Before covid, we would
spend many Sunday afternoons in coffee shops building prototypes of
whatever our latest and greatest idea was... most of these fizzled
out after a few weeks or so For 2020, we wanted to take the idea
of "building something people want" a bit more seriously. We
started off trying to build SaaS tools for ocean freight logistics
companies. That failed, but we learned a ton in the process. After
our experience in freight we wanted to work on tools that are a
little closer to home and tried a completely new idea: a web app
that makes it super easy to manage and deploy simple cron jobs and
other recurring/scheduled tasks. One thing we learned from the
feedback on this product was how difficult it can be to set up and
schedule email campaigns. This definitely resonated with us since
we've both had this pain professionally. While working at Stripe,
one particularly painful project Alex worked on was setting up
email campaigns to notify their customers of new regulations. I had
a similar experience at Pivotal where I worked on a project to
email users about security updates. So we started tackling this
particular pain point: setting up and managing email campaigns. A
few companies already do this pretty well. Intercom is one, but it
can be prohibitively expensive. And for companies that have
concerns about sending their customer data to 3rd party services,
these products aren't an option. At this point we figured, why not
be more ambitious? Instead of just building an email campaign tool,
let's build an open core alternative to Intercom! So here we are.
We're starting off with chat but we plan on expanding into email
campaigns and push notifications. We chose chat to start off with
because we wanted something that we could use immediately. For a
lot of our previous projects, we had set up chat on our sites to
engage with customers. We've launched this repo under MIT license
so any developer can use the tool. The goal is to not charge
individual developers. Features like chat, canned responses,
private notes, and auto assignments will stay free and open source.
Right now we plan on making money by providing things like a hosted
version and support contracts. We eventually plan on making a
licensed version where we charge for features that large companies
care about like Active Directory support, Okta integration, and
compliance exports. Finally we decided to build Papercups on top
of Elixir/Phoenix because it seemed like the best tool for a job
that requires a lot of "realtime" functionality and first class
support for websockets/channels. It's been great so far! The
frontend uses React/TypeScript. We may explore using LiveView in
the future, but we wanted to start off with a frontend stack that
we were familiar with. You can check out our repo at
https://github.com/papercups-io/papercups we have a ton of features
in mind would love your feedback and any feature requests! P.S.
This is our first time working in Elixir so would love any feedback
there too!
Author : cheeseblubber
Score : 156 points
Date : 2020-08-12 16:32 UTC (6 hours ago)
| mschrage wrote:
| Very cool! Congrats on the launch (site is super clean!).
| Implicated wrote:
| Any plans for any 'chat-bot' like features to handle the common
| questions/tasks that might be covered easily/in an automated
| fashion?
| cheeseblubber wrote:
| Yes! We're planning on releasing an open source bot sometime
| next 2 week. We have it working just need to integrate it with
| our platform. If you are curious of the details we're doing
| some fuzzy string matching with some neural networks.
| a13n wrote:
| Go hang out in the SaaS Growth Hacks group on Facebook and let
| people know you have a free / open source Intercom alternative.
| Every week people in that group are asking for cheaper
| alternatives, and usually they just care about the live chat
| portion of the product.
|
| I feel like one of the biggest pain points of Intercom is their
| pricing, and you should ride that wave as much as possible (in
| addition to "companies that are security and privacy
| conscientious").
| areichert wrote:
| We'll definitely check it out! And yeah, one of the top
| complaints we heard from people when doing user research was
| how expensive Intercom is, so definitely going to try to ride
| that wave as much as possible like you said :P
| jjeaff wrote:
| Ya, intercom is untenable for most anyone with a freemium
| model.
| foobaw wrote:
| Love this - Intercom is ridiculously expensive. One thing that we
| use Intercom is for NPS campaigns and also the product tours.
| Although I'd love to replace Intercom, not having these features
| means we can't switch easily. I wish we only used the Chat, then
| this would be the obvious product to use.
| areichert wrote:
| Makes sense! Would love to learn more about how you're using
| Intercom if you're ever down to chat :)
|
| (Feel free to email me at alex@papercups.io if you're
| interested!)
| thecolorblue wrote:
| Looks cool. There is a lot of demand for customer chat apps.
|
| What would it take to integrate with something like Google Dialog
| Flow?
| areichert wrote:
| Integrating with Dialogflow is definitely on our roadmap! We
| were thinking of starting off with a relatively simple bot that
| uses your FAQ to automatically answer common questions that
| come in, as long as the NLP model has a confidence score above
| a certain threshold. But certainly something like Dialogflow
| would give our users a greater ability to customize their bots,
| so we'd love to do that as well.
| CedarMills wrote:
| Congrats on the launch. Intercom is stupid expensive and this is
| a welcomed replacement, especially if all you use is the chat
| feature.
| tehalex wrote:
| We use intercom where I work, it's so expensive and tries to do a
| bunch of different things but is mediocre at most of them.
| Congrats and excited to see more.
| mrkurt wrote:
| Oh wow, I've been waiting for a self hosted app like this (with
| chat!). It's one of the few things I've missed since swearing off
| third party javascript.
| jedberg wrote:
| This looks great! Can't wait to try it out.
|
| Question for you. The other day there was an article here on HN
| where someone got rid of their chat bubble in exchange for a
| Chat/Help link in their top nav. [0]
|
| This gave them a 62% increase in chat engagements.
|
| Curious if you have any thoughts on this, since you're deeply in
| the space.
|
| [0] https://news.ycombinator.com/item?id=24059438
| areichert wrote:
| We definitely want to make our chat widget as unobtrusive and
| customizable as possible, so that our users can choose exactly
| where it shows up... I can sympathize with how annoying it is
| when these chat bubbles get "aggressive" e.g. by automatically
| opening and then sending me a bunch of messages from a bot.
|
| I really like the idea of just adding a nav item/link that goes
| to a page dedicated to messaging. Perhaps at some point we'll
| create a hosted page that does exactly that (e.g. maybe a
| custom "contact" or "FAQ" page where customers can ask
| questions, etc)
|
| In the meantime, our users should technically be able to set up
| a dedicated page for this, and just embed our chat widget on
| that specific page :) but we are going to keep thinking about
| how we can improve the UX for this kinda thing!
| Jommi wrote:
| If you look at the test in depth, the change and sample size is
| just terrible for getting any kind of real data.
| ponker wrote:
| I think Intercom and their relentlessly amazing Content
| Marketing is responsible for the whole "live chat" nonsense.
| Imagine I walk into a store just to browse. Do I want someone
| interrupting me and asking me if they can help me with
| something? Not really -- good retail employees do this only
| when a customer actively looks like they could use help. Do I
| want a humanoid robot asking me if I need help, then when I ask
| for help, saying "sorry I'm just a robot and don't know
| anything, please come back tomorrow and an employee will help
| you?" Hell fucking no. Do I want an employee waiting out of the
| way to help me, who will come to me as soon as I say "excuse
| me" and answer all the questions that I have? Of course I do.
| cheeseblubber wrote:
| Yeah definitely! Depending on how the site uses the chat bubble
| it can be annoying to the user if it blocks the site or
| randomly pops up. I think the author did a good job of getting
| a good number of samples and write up.
|
| One thing that makes this a bit harder to compare is that the
| chat widget is at the bottom of the page where as the Live Chat
| & Support link was up top right. Which catches the user's eye
| much more so might not make this as an accurate of an A/B test
| as it could have been
| Axsuul wrote:
| A better test would've been to have "Live Chat & Support" on
| the bottom right
| eggbrain wrote:
| First off, very cool tool. README looks nice, demo looks nice,
| website looks nice, code quality looks nice, and in general the
| whole "product" aspect of it looks very good.
|
| My main concern is that your competitive advantage seems to be
| that you are a free /open core chat tool, but this advantage also
| attracts many bad customers. They'll want a chat tool that
| features-wise rivals a competing (paying) platform, but also with
| the added twist that, by being somewhat open-source, they'll also
| want support for their weird edge case setup that you didn't
| consider ("Why won't this work on a Raspberry PI?", "Can I use
| this on my company's intranet?", "Do you work on Windows 3.1?",
| etc etc).
|
| You'll add in more features and support for these things, only to
| find the rabbit hole going deeper and deeper -- and identifying
| the customers that are actually willing to pay becomes harder and
| harder as you have to filter out a lot of the low-quality
| requests.
|
| To help with filtering, you can push people to the hosted version
| where they have to pay, but now you've lost the competitive
| advantage -- and have to compete with the many other chat tools
| in the space.
|
| I think there's still a lot of room here, in the same way that
| Gitlab carved out a huge niche from Github, but those would be my
| main concerns.
| areichert wrote:
| This is great feedback, and definitely something we'll need to
| think about. I had a similar issue at a previous startup I
| worked at, where we were basically building SaaS tools for
| logistics departments at commodity trading companies, and
| everyone had different edge cases/integrations they wanted from
| us. It's definitely a rabbit hole I want to avoid...
|
| You mentioned Gitlab, and we're trying to figure out how we can
| borrow from the playbooks of companies like them (e.g.
| Mattermost, PostHog, etc.)
|
| For now, we're just focused on getting users to figure out what
| the most common feedback and feature requests are, but longer
| term we plan on carving out a smaller niche and figuring out
| what our "target persona" is.
|
| Curious, do you have any advice on how to avoid these pitfalls?
| eggbrain wrote:
| > Curious, do you have any advice on how to avoid these
| pitfalls?
|
| I can tell you some things I've found helpful, but I think
| sytse (https://news.ycombinator.com/user?id=sytse) or antirez
| (https://news.ycombinator.com/user?id=antirez) could give
| better advice than I ever could.
|
| Off the cuff, for me it always comes back to having a good
| filter -- which can take time to develop, and can depend
| heavily on what your goals are with the open core part of
| this, along with what the goals are of the company.
|
| For example, if 10000 users want support for feature X, but
| 10 users are willing to pay/upgrade to support feature Y, and
| these features don't overlap (or are mutually exclusive), you
| many need to make a choice as to which way your goals will
| point you.
|
| Luckily, there will be also a ton of features/improvements
| that will neatly overlap with everyone, and so you can make
| everyone happy as well. For prioritization of those, there's
| a lot of things you can do, but I always like this article's
| approach: https://www.defmacro.org/2013/09/26/products.html.
|
| Another useful tool could be analytics -- the people that use
| your product the most are usually the people that become your
| biggest supporters, best suggesters, and paid clients. This
| might be a bit tough since if you add in an analytics tool to
| the codebase anyone could rip it out when they have access to
| the code, but you could do things like watch who is
| constantly submitting tickets / issues, reaching out via
| email, mentioning on social media, etc.
|
| Just some quick thoughts, but by no means am I an expert
| here.
| areichert wrote:
| Thanks for the reply! This is super helpful :) The defmacro
| article was a great read, definitely some great points in
| there.
|
| We're starting to realize how important having a good
| filter is -- a ton of people have opinions on what we're
| building, and we have to figure out how to distill/filter
| that feedback effectively (because a lot of it likely falls
| into the "distraction" bucket haha).
|
| re: analytics, that's also something we're trying to figure
| out how to do well -- like you said, it's tricky if folks
| can just rip out that code if they want to, but we're
| hoping that we can set up analytics tools that are
| beneficial to both us (for product insights) and our
| customers (e.g. to make sure everything is working well for
| them, alerting them to updates, etc)
|
| Thanks again for your thoughts!
| AsyncAwait wrote:
| Not that you're necessarily wrong, but you can 'fire' those
| 'customers' too.
|
| The answer is not to not release as open-source.
|
| I find it a tad hypocritical that 99% of people who post on HN
| consume tons and tons of open-source every day and yes, they
| also want the edge cases to work and yet, not only are they not
| actively participating to make the body of free (as in freedom)
| software larger, they're actively discouraging people from
| contributing.
|
| From my perspective, it seems to have been a great choice to go
| open as far as increasing adoption/buy in for GitLab, why not
| this?
| eggbrain wrote:
| > Not that you're necessarily wrong, but you can 'fire' those
| 'customers' too.
|
| For sure -- and you should! But in my mind, the goals of FOSS
| can differ wildly from a company wanting to release a great
| open source product, but also turn some of those users into
| paying customers. If your goal is simply the betterment of
| free software for developers, you take any and all
| contributions, as long as the code is of good quality and
| solves someones needs. If your goal is to figure out what
| features are needed by people who might be willing to pay if
| they were solved, you then have to figure out a way to filter
| the contributions and what you're willing to contribute back.
| It's just a trade off.
|
| > I find it a tad hypocritical that 99% of people who post on
| HN consume tons and tons of open-source every day and yes,
| they also want the edge cases to work and yet, not only are
| they not actively participating to make the body of free (as
| in freedom) software larger, they're actively discouraging
| people from contributing.
|
| Working in open source is tough -- it's many times a
| thankless job. I was one of the team members of Kandan
| (https://github.com/kandanapp/kandan), which was a Slack
| clone with ~2.5k stars, and as much as we helped people,
| sometimes it also felt like it never was enough.
|
| One of the few helpful things that came from being true FOSS
| was that most people had an understanding that we did this as
| volunteer work, so they weren't upset when features or
| changes took long, or weren't merged into the app. But if the
| goal is to eventually move customers into other products, or
| onto a premium tier, it becomes a different game with
| different rules.
| riffic wrote:
| It's so weird to see proprietary vs. free software concern
| trolling on Hacker News, yet here we are.
|
| It's 2020, I think people understand how to build a business
| model around FOSS these days.
| mceachen wrote:
| Congrats on the launch, and best of luck to you and your team!
| jjeaff wrote:
| This looks great and an open source option in this field is
| needed.
|
| From demos and docs, I'm only seeing the chat. Does papercups
| also have some sort of customer database that is filterable and
| segmentable?
|
| Because to me, that is more about what intercom is about.
| riffic wrote:
| ChatWoot is another open source alternative, unless I am
| fundamentally misunderstanding what Intercom is.
| areichert wrote:
| Intercom also does a lot of things on top of chat like email
| campaigns, FAQs ("articles"), chat bots, and is somewhat
| evolving into a bit of a CRM.
|
| Chatwoot focuses on chat as far as I can tell (and so do we
| at the moment!), so it is certainly another viable
| alternative if that's what you need :)
| cheeseblubber wrote:
| Thanks! We don't have it right now but the customer database is
| something we wanna work on very soon. There are still a bunch
| of features we wanna work on for chat and we're trying to work
| out the balance between making the chat great and working on
| other features like email messaging and better customer
| database
| sandGorgon wrote:
| This is a brilliant product and something that needs to be built.
|
| Gitlab for Intercom.
|
| One feedback though - the whole value here is the product. I
| would suggest not building your transport at this point and
| making Pusher/Pubnub/Firebase/Ably pluggable as transport.
|
| 99% of your tickets will be "my message wasn't delivered"
| otherwise and it will take you years to perfect this ...which is
| something that has been reasonably solved at very cheap cost.
| gmays wrote:
| +1 on this, subpar transport would be a dealbreaker and this is
| a solved problem.
| areichert wrote:
| Great feedback, we're definitely planning on taking that advice
| :)
| sandGorgon wrote:
| On the pluggability topic, please also make it pluggable with
| chatbots like Dialogflow (just like Kommunicate does it)
|
| Massive value add.
|
| You can generate a lot of dealflow from upwork and Fiverr.
| gmays wrote:
| Congrats! Looks great, will keep an eye on this. Any plans to
| support mobile via Expo? That's one of the big drawbacks of
| Intercom right now:
|
| * https://expo.canny.io/feature-requests/p/add-intercom-suppor...
|
| * https://community.intercom.com/t/intercom-widget-dont-want-t...
|
| * https://github.com/expo/expo/issues/335
|
| * https://forums.expo.io/t/intercom-integration/761
|
| * https://forums.expo.io/t/integrating-intercoms-js-snippet-as...
|
| * https://forums.expo.io/t/is-anyone-using-intercom-and-having...
| fjarrett wrote:
| +1 not having a pure JS Expo SDK is a huge blind spot for
| Intercom if you look at all the people over the years who have
| been asking for it - maybe this project can take advantage of
| that
| fortydegrees wrote:
| Yep, no react native support is maddening to me with intercom.
| A dealbreaker.
| stevenpetryk wrote:
| Intercom employee here. Do you mean embedding the Messenger
| in a React Native app?
|
| I'll pass this convo along to the Messenger team. It sounds
| like a worthwhile thing to look into since RN is becoming so
| popular.
| gmays wrote:
| Thanks for chiming in and passing our feedback along--much
| appreciated.
|
| In addition Messenger I'd also add Mobile Carousels. A pure
| JS Expo SDK is needed to support these. I think you'd be
| surprised how many apps are mobile only these days and
| would love to use Intercom, but are turning to other
| options like this instead.
| cheeseblubber wrote:
| I haven't checked out expo yet. We have a react component that
| you can install https://github.com/papercups-io/chat-widget or
| https://www.npmjs.com/package/@papercups-io/chat-widget Will
| have to do some testing to make sure it works.
| Abishek_Muthian wrote:
| Congratulations on the launch, Papercups.
|
| I want to pick your minds on a tangential need gap - 'Customer
| Messaging on a website without website owner's action'[1] i.e.
| Enabling anyone to chat with other visitors of any website,
| unlike customer messaging this will be consumer focussed and
| there seems to be some products addressing it but naturally
| affected by _Chicken and Egg_ problem.
|
| What's your take on that need gap?
|
| [1]https://needgap.com/problems/141-youtube-like-public-chat-
| fo... (Disclaimer: This need gap was posted on my problem
| validation platform).
| jaywalk wrote:
| Sounds a lot like Dissenter https://dissenter.com/
| alooPotato wrote:
| Maybe there is a way to utilize the website owner to bootstrap
| the chicken and egg problem.
|
| So i'm assuming 'Customer Messaging on a website without
| website owner's action' would be a browser extension? If so,
| what if you made the pitch to website owners that if they
| signup and just embed your chat on their site, then they are
| allowed to moderate the content. Otherwise, users that have the
| extension will be able to just chat about the website owners
| products without moderation.
|
| Once you get embedded on a bunch of websites, then you can
| offer an upgrade path for those users to get the extension and
| chat on any website.
|
| Just an idea!
| areichert wrote:
| This is a really interesting idea! Never thought of doing
| something like that, but if enough people want it, we'd
| probably be happy to build it :P
| lukevp wrote:
| Congrats on the launch! Hope one day to need a chat solution for
| something I build :)
|
| Elixir is interesting for the resilience of BEAM and being FP
| oriented, and LiveView is a neat concept for templating HTML, but
| if you are already building a react/typescript front end you
| wouldn't get much use out of LiveView. My concern would be issues
| finding developers to work with that stack and lack of tooling
| and support outside core libraries.
|
| C# has a very mature product called SignalR that can be used for
| real time communications with fallback to long polling / SSE for
| legacy browsers. It is a perfect fit for chat apps. Not sure how
| far you are into the backend development, but wanted to point out
| this competitor in case you hadn't heard of it. .Net is cross
| platform, has a good ORM, and a ton of industry support as well.
| Kestrel performance is fantastic.
| areichert wrote:
| Interesting! I'm honestly pretty unfamiliar with C#, but I'd
| love to check it out and I'll definitely look into SignalR :)
|
| I think one thing that's been really nice about Elixir is how
| helpful the community has been, and what an approachable
| language it is for someone like me coming from a Node/Ruby
| background (and dabbling in some Clojure :P). It's been really
| easy to get up and running, and also is just a fun language to
| work with.
|
| So far finding developers to work in this stack has not been an
| issue, and we're hoping doing a project like this will attract
| even more developers to Elixir :)
| cpursley wrote:
| The problem is not finding Elixir developers, it's finding
| Elixir jobs.
| areichert wrote:
| Sounds like a good problem, if we're one of the few shops
| offering Elixir jobs :P
| bredren wrote:
| Congrats on launch and thanks for the story.
|
| It seems like there is convergence between instrumentation
| (analytics events) and messaging.
|
| Do you think this is the case? If so, do you plan to tackle this
| as well? If not, how would this slot in alongside Mixpanel or
| Amplitude?
| cheeseblubber wrote:
| Yes we see that trend as well. For messaging existing customer
| its super nice to have messaging and analytics in one place.
| One common example is you wanna send deals or coupons for
| people that meet some threshold.
|
| Some analytic features we have on the near term roadmap are
| features like log rocket where you can get better insight on
| what the user is doing at the moment. The vision is definitely
| to become a centralized location for messaging and marketing
| data. We're still trying to figure out the balance and how much
| we wanna focus on analytics.
| bredren wrote:
| If you were to offer an adjacent product that did event
| logging and integrated with your messaging product it would
| be interesting to me.
|
| I've tried using amplitude and building my own messaging and
| it is too much work.
|
| Right now I use mixpanel and am prepared to pay for the
| product mix.
|
| If you do this, and they are separate instances, I would want
| to see it have a simple docker container-based Setup. For
| example, configure this app with just some env variables and
| use our images.
|
| I'd also recommend you focus on django at first and make
| setup on that framework easy and well documented.
|
| Good luck!
| areichert wrote:
| Have you looked at PostHog?
| https://github.com/posthog/posthog
|
| Seems very similar to what you're describing :)
| bredren wrote:
| Thanks for the link. Coincidentally a feature request to
| mash posthog with messaging went into an issue 10 hours
| ago!
|
| https://github.com/PostHog/posthog/issues/1414
| horizontech-dev wrote:
| Very nice. Curious can you compare and contrast with
| https://www.chatwoot.com/ (looks like they are also similar)
| riffic wrote:
| more players in this space is definitely a good sign. it (in my
| opinion) means the idea is viable and competition is healthy.
| cheeseblubber wrote:
| Yep! One thing that we wanted was to make our more customizable
| and hackable. So we have a React component you can install with
| https://github.com/papercups-io/chat-widget. We want to make it
| highly hackable and a bit more developer focused. But at the
| moment we are very similar to chatwoot and love the work they
| are doing.
| areichert wrote:
| To add on a bit -- it ~seems like chatwoot is just focusing
| on chat (which is exactly what we're starting with), but we
| do plan on expanding to other products beyond chat :)
|
| (chatwoot may be doing that as well, but just wanted to
| mention it!)
___________________________________________________________________
(page generated 2020-08-12 23:00 UTC)