Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Launch HN: Twenty.com (YC S23) – Open-source CRM

news.ycombinator.com

Post reply on HN
Print view View original

161–170 of 317 posts

Re: Launch HN: Twenty.com (YC S23) – Open-source CRM

#161

Post by Bonapara »

bravura wrote: post #151
Closi wrote: post #140

Best of luck! Generally agree with launching early - although this feels very early! We are currently looking for a replacement to our HubSpot account (20 person company for context with c4 people who use HubSpot - so probably a potential customer!), however this appears to be very buggy to start with and misses some basic functions: * Doesn't seem to be a way to name / describe an opportunity (pretty fundamental) *…

What don't you like about hubspot?

First we have a lot of respect for what Hubspot built. On the short term, we feel that the UX could be improved. On the long run we want to make Twenty easier to customize. (In the previous companies we founded we each had to build our own in house CRM).

Re: Launch HN: Twenty.com (YC S23) – Open-source CRM

#162

Post by phkahler »

charlesTwenty wrote: post #64
nathanstitt wrote: post #42

Congrats on launching! It looks like you started with Hasura GQL and switched to your own implementation ( https://github.com/twentyhq/twenty/pull/156 ). Would it be possible to comment on what influenced your decision here? I've built ontop of Hasura in the past and it's permissions model seems like it'd be a good fit for a CRM

Sure! We want to build something flexible where users can define their own custom objects and fields. We were thinking about leveraging Hasura that's already providing a flexible graphql API based on metadata which is exactly what we need / will need to build in the future. However, there are three reasons that pushed us to go through a different way: 1) We want to build a cloud version which is multitenant (I person…

The multitenant sharing of one large table with uuid seems rather crazy.

Re: Launch HN: Twenty.com (YC S23) – Open-source CRM

#163

Post by phkahler »

charlesTwenty wrote: post #64
nathanstitt wrote: post #42

Congrats on launching! It looks like you started with Hasura GQL and switched to your own implementation ( https://github.com/twentyhq/twenty/pull/156 ). Would it be possible to comment on what influenced your decision here? I've built ontop of Hasura in the past and it's permissions model seems like it'd be a good fit for a CRM

Sure! We want to build something flexible where users can define their own custom objects and fields. We were thinking about leveraging Hasura that's already providing a flexible graphql API based on metadata which is exactly what we need / will need to build in the future. However, there are three reasons that pushed us to go through a different way: 1) We want to build a cloud version which is multitenant (I person…

[dupe]

Re: Launch HN: Twenty.com (YC S23) – Open-source CRM

#165

Post by tomnipotent »

> Making it easy to connect data sources, and fetch data in real-time like in BI tools

Please don't roll your own and rather leverage other FOSS projects, such as Airbyte (or Singer). This also puts you in a better position to leverage those tools to push local CRM data to upstream providers, which are incredibly common place for custom workflows.

Re: Launch HN: Twenty.com (YC S23) – Open-source CRM

#166

Post by charlesTwenty »

noizejoy wrote: post #149

If I was running a company of any meaningful size, I would hesitate to allow any 3rd party to become the OS of my company. The OS of my company should be at the very core of my company - highly customized to give me an edge rather than to level the playing field with my competitors. And that means becoming very good at creating and maintaining the internal IT vision and expertise to make that possible. And that in tu…

Thanks for the feedback! We have been discussing this a lot. Here is one of the option we have in mind for the upcoming months and we would love to know if this could work in your opinion.

Data ownership:

a) Twenty makes the distinction between Twenty owned data models (People, Company, Pipeline) and your own data models.

b) Let's say you use the cloud version: you can plug your own external database as a datasource. You would be able to describe your own data model through config file, Twenty would understand it and will keep in sync your data with the one stored in Twenty. Your data will remain the source of truth regarding whatever is tied to this datasource.

c) So, if you wish to switch to self-hosted, you can, you will have to transfer Twenty owned data to into your own instance through exports / imports. You would not have to transfer your own data as this was already configured as an external data-source.

Extensibility:

a) Twenty is exposing a GraphQL API on top of your data that you can leverage. It doesn't matter if you are using the cloud version or if you are self-hosting it.

b) We are thinking about a plugin system. To enable that, we plan to provide developers API for both FE and BE that will keep consistent between the different versions of Twenty (of course, they will likely be some breaking changes between major versions but hopefully minimal so you can keep using the latest version of Twenty).

c) you can build anything you want using these 3 apis, either an external tool leveraging the GraphQL API, either a front-end plugin on FE API, either a backend plugin on BE API. You will be able to deploy your plugins to the cloud version (we will make sure they only impact your own tenant, which is challenging technically). Here too, if you choose to move to self-hosting, you will obviously also be able to write and deploy your own plugins on your self-hosted instance

So, if we provide stable APIs and are able to safely run custom plugins into the cloud, it doesn't matter if you are using the cloud version or the self-hosted version. As both are using the exact same source code, you should be able to switch between the two quite easily. If you self-host, you completely own your data, if you use the cloud you don't but you can still fully benefit from Twenty APIs and extensibility.

Re: Launch HN: Twenty.com (YC S23) – Open-source CRM

#167

Post by Bonapara »

tbrooks wrote: post #146

What does Twenty do that Close doesn’t or can’t do? (I’m a huge Close fan.)

Close is a strong source of inspiration for their opinionated approach. We hope that we can make the difference with the User Experience in the short run (For instance you can uses blocks in notes). In the mid run, open source sounds like a big differentiator as you will be able to customize Twenty to your needs.

Re: Launch HN: Twenty.com (YC S23) – Open-source CRM

#168

Post by Bonapara »

diggertrock_ng wrote: post #50

Our team has recently found an open-source sales management CRM tool, Meow https://www.sales-funnel.app/ , which they are happy with. Licensed under AGPL, it might be worth a look for startups. I guess there are definite reasons why open-source isn't as successful in the CRM space. Buyers are mostly not developers and the requirements for a CRM are often very diverse. I agree with earlier comments, Salesforce is not…

Thanks for sharing! We have indeed two personas in our target: devs & Sales/leadership. We believe one will bring the others as Odoo did for instance.

Re: Launch HN: Twenty.com (YC S23) – Open-source CRM

#169

Post by charlesTwenty »

tomnipotent wrote: post #165

> Making it easy to connect data sources, and fetch data in real-time like in BI tools Please don't roll your own and rather leverage other FOSS projects, such as Airbyte (or Singer). This also puts you in a better position to leverage those tools to push local CRM data to upstream providers, which are incredibly common place for custom workflows.

Yes, agree! We try to re-use as much opensource software as possible. One difficulty is that we are also trying to make it as easy as possible to self host the CRM. If we start including all these tools by default, it will be hard for people who self host to manage all these tools.

Our current plan is to have Twenty supporting different drivers for everything. By default, you only have the basic ones implemented (let's say CSV import + direct connection to Postgres). Then, if you wish and take time to add the right configuration, you can activate Airbyte, Segment...

The same goes for file storage for example: by default we use local storage, but we also make S3 drivers)

On the cloud version, we would of course made all these drivers available.

Re: Launch HN: Twenty.com (YC S23) – Open-source CRM

#170

Post by nathanstitt »

charlesTwenty wrote: post #64
nathanstitt wrote: post #42

Congrats on launching! It looks like you started with Hasura GQL and switched to your own implementation ( https://github.com/twentyhq/twenty/pull/156 ). Would it be possible to comment on what influenced your decision here? I've built ontop of Hasura in the past and it's permissions model seems like it'd be a good fit for a CRM

Sure! We want to build something flexible where users can define their own custom objects and fields. We were thinking about leveraging Hasura that's already providing a flexible graphql API based on metadata which is exactly what we need / will need to build in the future. However, there are three reasons that pushed us to go through a different way: 1) We want to build a cloud version which is multitenant (I person…

Ah, yep that makes complete sense if you want to per-tenant schemas. My app is multi-tenant but all have the same schema. We use a customer_id column that's matched against the JWT's customer_id token to ensure that no data is shared inadvertently by a dev missing adding a WHERE clause.

Thanks for the SF link, that's quite interesting. It seems bonkers to me to throw away all the advantages of the RDMS but you can't argue with their success.

A middle ground I've encountered in an ERP system (prophet21 if you're interested) was each table had multiple "CUSTOM_XX" columns that were initially blank. Customers could edit their UI and would drag/drop the custom columns onto the appropriate form and change the label to be whatever they'd like. That gave them some flexibility but kept the core schema coherent.

Post reply on HN