Hacker News new | past | comments | ask | show | jobs | submit login
Launch HN: Twenty.com (YC S23) – Open-source CRM
415 points by iFelix on July 19, 2023 | hide | past | favorite | 311 comments
Hello HN,

Seven years ago, I complained about Salesforce on HN. Somebody said: "one day, someone will do better". That stuck and today we're trying to be that “someone” with my co-founders Thomas (design) and Charles (eng like me). Our company is called Twenty and our repo is here: https://github.com/twentyhq/twenty

We want to fix two issues: most CRMs aren't enjoyable to use and they often clash with engineering teams.

YC encouraged us to launch early. What you see now is about two months' worth of feature development. Our tool only does a small part of what big CRM players offer, but we focused on providing a great user experience on the basics, instead of spreading ourselves thin across a vast range of features and delivering them half-heartedly. Plus, we've found that many small companies like the product as it is because they don't need all the complex stuff.

Once we have covered the basics, we’ll soon be working on three big features: - Moving to a robust metadata-driven architecture; - Providing innovating ways to extend the CRM with Typescript; - Making it easy to connect data sources, and fetch data in real-time like in BI tools.

The startup world is littered with ghosts of so-called "Salesforce killers", so we know it sounds naive to pitch ourselves in a similar way. But we think that if someone ends up changing this market, it will most likely be through a community-led effort. And there hasn’t really been any serious attempt to start a great new open source CRM in the last decade.

Twenty is built with Typescript, React, and NestJS with GraphQL, and licensed under AGPL. We plan to make money by offering a hosted version. Our docs are here: https://docs.twenty.com. Try on cloud: https://app.twenty.com.

Dev setup and demo: https://www.loom.com/share/7b20b44d8d5146fea8923183511bb818 (Loom said they couldn’t provide a transcript because they don’t support “language other than english” haha... apologies in advance!)

We’re very eager to get your feedback as we haven’t launched anywhere before this post. What's your CRM story? What should we prioritize next?




I work at a company that uses Salesforce as the system that runs the whole business. CRM barely touches on what we use it for.

We use it for inventory, logistics, accounting, customer support, managing our partners (dealers), managing our suppliers... as well as sales.

I spent 2 years as a Salesforce developer, and still dabble in APEX from time to time.

All of that is context for what I'm about to say:

Salesforce is a nightmare to develop and maintain. The concept of a central system to run the whole business makes sense. But Salesforce has no focus, IMHO.

I like how simple and easy to use Twenty is. But what I'd love to see is something like AirTable. Yes, call it a CRM so that you have an instant use case. But make it easy to do custom development. Make sure there's a great API. Much like Wordpress, make it easy to know where I can safely extend the platform.

Do all of that, and I think you might have a winning product!


To be honest, it sounds 100% like SAP / ABAP. A lot of terribly outdated stuff. But it can do everything you can imagine. If it can't, there's 1-2 recommended products that expand features on top of SAP.

The moment your business wants to do things a way that isn't SAP's way, you completely butcher everything though. See https://news.ycombinator.com/item?id=17541092


My first internship was as a Dynamics AX dev. Me and another guy. Our mentor was a super-duper senior architect something something. He once asked us what we were planning on doing, career-wise, and we were kinda surprised; obviously we were working towards becoming Dynamics AX devs, and were hoping for a job at that place.

He got a somewhat wistful look in his eyes, and said (more to himself than to us) he wished he could go back and choose not to do that.

I'll never forget that. He was earning an insane amount of money, working super high-level at one of the largest IT firms in the country.


I think a lot of ERP stuff is like that - pays well but few people regard it as fun - not least of which is that end up with knowledge of very niche technologies that don't really progress very rapidly.

Edit: Mind you for job security and cash generating potential they are can be pretty good - years ago I knew of people on £3000 a day in the UK working on very niche financial systems - but you basically had to have a lot of domain knowledge (financial consolidation) and decent development skills.


Honestly, I do mostly web development and unless you're really interested in the product (which is far from a given) why do you care if it's an ERP or ecommerce or some travel application?


My guess: If you are implementing any type of software, you usually see an UI, input and output. For SAP and ERP you can also have this.

But it's really ugly, messy, and you might have to implement 5 corner cases of what the german government has thought of to complicate the lives' of everyone in regards to capital gains taxes in combination with church taxes, in a year in which you got married but one of the two left the church the same year. Oh, and what if you also got a kid that year and moved cities? And during implementation there is another law passed to change stuff?

In other words: So out of the world that noone finds it interesting anymore :D


Part of the problem is that the final output from SAP is typically financial reports that need to conform to standards. That limits the design flexibility of any modules or core components that touch anything that might need to be accounted for. Anyone who has done custom systems development in this space are painfully aware of this. This is aside from the non-business logic parts ie counterintuitive development idiosyncrasies.


SAP was in such a lucky position in tech history... they did solve a problem that was extra profitable for them, but they got greedy and sedentary on the glut...

And then it just became too expensive for their clients to move away. (i hate that company)

but the marketplace for displacement in this space is still ripe, else we wouldnt be seeing startups like this.


Thanks! One of the reasons there hasn't been that many good alternatives is indeed that the product surface is very big. We asked ourselves before launching here if it was too early but the reality is that there will always be more features we can build. Odoo is an example of a super successful open source project in that category but it took them many years of development to get there. I hope that we can find a product market fit faster, by starting with simpler CRM use-cases and expanding slowly to new use-cases (CPQ, Marketing, Commerce) once we've got the basics right.


To be brutally honest, Airtable is a dog to get data out of... the sync is delayed, the API calls to pull data are atrocious and the cost/complexity to exfiltrate data from Airtable is hugely prohibitive.

I wouldn't use that as a source of inspiration, at least not on the "connectivity" end.


Maybe so but it’s incredible as a rapid prototyping tool to solve actual business problems at reasonable scale and it’s one of the few platforms that is constantly improving in intuitive ways.

Emulating AirTable usability with a CRM focus would be a category killer if successful.


Nothing pisses me off more than non-devs saying how AirTable is for devs when all the devs I know hate interfacing with it or having to work with it.

If you want pretty spreadsheets, cool. If you want to use this as a CMS or CRM, and it has to interface with an external tool, god rest your soul.

edit: a candid example, we were using it to track some payables for advertising campaigns. Marketing team (that likes airtable) was adding the invoice as a file field to the table. That file attachment is not added to any "email" or "external" sync features of airtable, making it impossible to add it programmatically to an accounting software or to a shared accounting drive. Using zapier doesn't fix it since it's just not the file or a link to it in any of the api calls, only a reference field. It also doesn't export when you do an export of the table. You have to manually go in and download the file from each record (in the ui) which makes putting it there vs dropping it into a shared drive pretty useless as far as time savings is concerned.


I’m a developer and have run development teams. I fucking love Airtable for solving business problems.

I love it for the same reason I love XL, which is that you can turn it on and it just works and normal people can use it. You can create a sheet that tracks something important to the business in 20 minutes, and you have built in slack notifications and cron-type job capability and the ability to call or be called via REST API and so on, plus easy to follow user management and row level commenting and so on all built in.

In the first 20 minutes.

Yeah there’s stuff it can’t do or is bad for. When you get to that stuff use another tool, and guess what you usually can use whatever you did in Airtable as a spec instead of trying to sort out what the business process actually needs in terms of fields and so on.

I absolutely love it. It’s been an incredibly helpful addition to what had been our previous stack of salesforce for CRM and our own rails app/site, and is just so much faster for creating internal business tools than either.


Are you interfacing with external apps or systems? If you can keep everything INSIDE airtable, it gives a lot of value out of the gate. If you need to tie into it externally, it's a pain in the ass and some things are simply not possible.


I'm the founder of a startup (www.getsubsystem.com) that builds solutions on top of Airtable, so I'm familiar with their systems. While it's true that their REST API has some sharp-edges, particularly around linked fields (columns), rate-limiting, and filtering records, I think it’s mostly solid and user-friendly.

Getting records from a table is as straightforward as making an API call to: `/{baseId}/{tableId}`. For getting the actual ids, there's a metadata API. The docs are also quite comprehensive. I’m curious as to where you have run into issues?


As a user of airtable and not a developer of an airtable app/plugin, the api calls are burdensome (dereferencing lookup fields, data types) and if you want to do any serious work on large bases, you hit rate limits/call limits very quickly.

They make it trivial to import/push data in but accessing it or pulling it out looks like an intentionally hindered dark design pattern (like egress on aws). I have resorted to writing extension scripts in their godforsaken nonstandard javascript framework to access and aggregate data before pushing it out. Accessing google sheets programmatically is a walk in the park, comparatively.


Template library.

There should be a template library and a way to do a really high-level business model NODE style work flow and it pulls the templates needed to make that

A NODE TREE builder for a crm would be valuable, if it doesnt already exist - start with "departments" and then have children recommendations for each, such that Inventory is a Child of Receiving and all the requisite models/modules in such....


The context is the explanation: they don't need to excel because they've got you. Every business should consider this when picking solutions.


Hi Ifelix, I have been working as Siebel Consultant implementing it in many companies and then later moved to Salesforce which I also work implementing/changing it for companies needs.

As a fullstack developer I already thought multiple times to "create my own Siebel" or "create my own Salesforce".

But I faced that, the CRM part of it is very easy to implement. That is why there are so many players on commercial CRM area (Pipedrive, Insighlty, etc) and even on open-source (vTiger, SugarCRM, etc).

But what makes Siebel and mostly Salesforce different is their power of customization.

Imagine that there are entire careers (including mine) built on top of customizing such applications.

I know current state of Twenty is just the start, but I'm wondering how different from vTiger, SugarCRM and other opensources solution is Twenty? Besides the UI design that is really clean but, from my experience, is not so much what final users thinking when choosing a CRM, if you want to compete agains the big players as you stated in your CTA: "Building a modern alternative to Salesforce"


I think bringing in typescript as a privileged "plugin" language and all the libraries available under it, would speed up any custom development on the long term. Those "custom" use cases can become native ones and the base platform can gradually grow to be more powerful.

I think it's smart to bring in a common language for plugin/application design and focus on making the plumbing and interface (not just UX) first class.


Curious why did you think about building you own? For us the frustration came primarily from the design, the developer experience to extend/customize, and the way data is pulled and fetched. I think that if we nail those 3 points, we would have a solution that is well enough differentiated from what currently exists in the market


Well, first of all, becaused we are all trying to build the new [put_some_big_company_name_here].

But besides my entrepreneurship, I think the space for building such application goes to 3 routes:

1) Build one "traditional" CRM, to handle accounts, contacts, oppportunities, etc, etc. Without or just few customizations being possible. So then you felt in the "commodity" bucket to compete with all other CRMs in the market (and I'm not talking about Salesforce).

2) Or you build something for a niche/vertical so then you can specialize it for a specific scenario. Like a CRM for kindergarten schools, so then you can make it a 100% fit with their business. This way a few customizations are enough since the product is already made for them.

3) Build such a robust solution that allow the user/consultants customize them as the client which allowing them to achieve any kind of requirements the company has to deal with their clients, and believe me, from mid-size to big companies they have a lot of different customizations, automations and integrations needed for deal with their customers.

I was thinking to build the third one, because that is where the money is. BUT, that is a huuuuge job for a one-man show.

So maybe starting with the 1 and eventually going to the 3 could be an option, maybe I will still invest time on it, since my know-how in CRM area is almost everything I know (I have been working on this for more than 20 years now).

But getting back to your reasons to create Twenty I think you can just let the design go if you want to achieve "developer experience/customization". Think that as you let the product be customized you can't keep it "clean" because the final user maybe needs a ton of fields for their use case, or something even weird like 3 screens to then create a record.

So, my 5 cents is: focus on power and ease of customization, that is what your potential clients would look for.

In terms of how data is pulled and fetched, I think you are talking about Graphql. But I think does not matter to much, as long you have a very specific way to, at least, allow 2 kind of integrations: Online (syncroous via API (rest or graphql or soap or anything) and Batch. The later is very important since as you are dealing with CRM, loading big amounts of data is a must specially when loading leads, contacts, etc.

Ah! One last thing, before going after Salesforce, try to compare Twenty to the current SMB alternatives like Pipedrive, Insightly, Zoho, Hubspot, Close.io, Less Annoying CRM, etc. They all have their own beautilful and productive UI so you need to look for being different from them.

That are my thoughts I did a lot of research on this market area already, so ping if you need something me at douglascorrea dot io


My (layman) path to growth suggestion would be to start with nr 2 using the mechanisms you describe in nr 3 internally ($1M to $3M ARR), and then slowly expand to comparable verticals until you have about $10M to $20M ARR. After that you can start productizing the internal tools you built to the public and become a platform.

(Mostly written from a GTM perspective, and including the obligatory disclaimer thatI'm still way below $1M ARR myself, so take this with a grain of salt...)


Thanks for taking the time to write this up! I'd love to chat more, especially on database design. I will reach out


Make it extensibe. Usually businesses require this little customization here and there and given you provide the customization points, excellent. OOTB hasn't worked well for me... probably I can use excel then more easily.

Consider Microsoft Power Platform / Dynamics 365 Customer Engagement/Sales for which I'm a developer. Obviously this is a behemot and much more than CRM, but it was born out of CRM! But I want to share things I love about the platform.

The following customization points for power platform goes a VERY LONG WAY to adjust CRM to business needs and I yet have to see a significant roadblock for any customization business has needed:

- Custom tables which are 1st party citizens in all the ways and doesn't have any shortcomings. It supports all the auditing, security model and ability to link to first party tables and other way around.

- Custom attributes for 1st party tables.

- Robust Plugin-Architecure - everything is a message (API calls, CRUD, special operations, etc) - I can "plug-in" into the pipeline either for my messages or 1st party messages and have pre-operations and post operations. I can do sync/async plugin. For sync plugin I can live within same database transaction and make it so that all the transaction succeeds or rollbacks if I choose it so.

- 1st party JS library API that enables limited interaction with the form (show/hide fields, set required, get/set values)

- An option to create own Custom APIs, add a plugin to API and you have a nice extensibility.

- Powerful, consisten WebApi for integration that also supports my custom tables and stuff - CRUD operations and API calls. Can build a completely custom client for the CRM if the platform is lacking somehow.

- Custom components framework - whenever builtin controls/JS is lacking, I can build full-blown control in my choice of JS framework that has particular integration points when hosted within CRM.

As I see it, consistency makes things like that possible.


I aspire to achieve all of this someday!

The key challenges I foresee are:

- Backend: offer extensibility that is powerful while secure in our multi-tenant cloud service.

- Frontend: ensure that custom plugins don't feel limiting while not disrupting the unified design, as the overall software appearance, not just the core, shapes the end-users' brand perception/experience


As for frontend - you could build reusable components and make possible to use them/build upon them. Microsoft made FluentUI to make consistent and usable components across product line. However each product customizes styling slightly and builds their own components that are not opened up... which is pity.

If you ever plan having different things, better keep them in mind at the beginning - bolting them in afterwards may be cumbersome.


Yes! We'll probably need to isolate some of the existing components and commit on their api stability so people know they can reuse them safely


Congrats on the launch.

My two cents: I work in marketing and CRM for eCommerce lifestyle companies. When I evaluate a CRM I try to understand if it's for sales or eCommerce or both. I see in your docs that you mention that specific point of sales being dominant in CRM so that's a plus.

Then I look at if it natively or easily connects to the tools that the company uses. If I'm pointed to using Zapier for connections that's usually too costly because you're collecting a lot of emails and you can quickly get into millions of calls for low quality leads.

Another big miss I notice is not integrating with POS systems and only eCommerce so that quickly creates an issue with companies opening stores.

On the sales side there's usually less of a sales pipeline and more of a clienteling side where you've got sales people at store locations reaching out to customers to announce products or services or events. It's a lot less of stages because products are usually not all that high value.


Thanks for the feedback! Especially on sales not necessarily being modelled as a pipeline, that's something we need to think of more. Integrations will come this year.


Alright so I'm going to say it: Make a local install please I'm begging you. As a 1-man consultant, I really don't want to: 1. Download docker or some other LAMP stack 2. Compile and run it 3. Launch a local database everytime I open it from my laptop 4. Voila! I'm into my locally server DB with a nice fronted.

No thank you. If you want adoption it has to be adoptable, and most open source crms (SuiteCRM, Odoo, ERPNext, Espo, Crust, Corteza, Civi, etc) I've tried them all. I'm now back to running an Excel workbook split into categories taken from a notion template.

Please just make this local :( It's gorgeous!


Interesting feedback! The recommended install is already local (through yarn).

The only piece mentioning docker is to provision a Postgres database, which you need to have to run a CRM anyway. We have planned to replace it by a section explaining how to install Postgres on the different OS. Planned for next week!


I think you need a js engine to run the entire thing which entails shipping that with the product to make it "locally installable". Then you get into complex version dependencies and require support for upgrading and upgrade paths... yarn is pretty straightforward and so are docker containers.


Haven't looked into the technical details of it, but it seems like this should be as simple as slapping it inside of electron to have a fully local and cross platform install.


Yes, that would solve the javascript interpreter aspect, but then you need to provide update services and updaters to customers, logic to update, an installer, support for said installer, testing for breaking changes to updates... It's more complicated than just bundling the code in a static wrapper.


They seem to have a pricing page so if you don’t want to do that then use the hosted one?


Yes! We've setup the pricing page for this launch to avoid disappointing users later on but we're not enforcing pricing at this point.


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 personally think that provisionning single tenant instance at scale is not a good vision in a world with restricted resources ; there is a significant resource saving when we mutualize resources). This means that different users can have different data schemas. This is not possible with Hasura that serves one unique schema for all users.

2) We want to offer a good developer experience and Hasura comes as a standalone service. This means that installing the project gets much more complex than a "yarn && yarn start", and creates a harder onboarding curve which we want to avoid as much as possible. If you face a Hasura issue during installation, you would need to understand Hasura workflows, and probably docker too.

3) Very similar to 2, we want Twenty to be easily self-hostable with 1-click to deploy. This would had pushed us to create bigger joint images including Twenty + Hasura, making it harder to maintain and to debug.

There is a great article on how Salesforce is built here: https://architect.salesforce.com/fundamentals/platform-multi.... They basically have 1 metadata table and 1 data table (uuid, objectid, orgid, field1, ..., field500) where each column is a VARCHAR and they have built their own engine on top of it. I think we will likely need to do something similar and we cannot build it on top of Hasura / we lose the value of Hasura by building on top of it.


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.


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.

> Interesting, I will look into that, thank you!


Regarding the different schemas / metadata, I would've thought that Hasura would still be super useful for everything else. So a custom API for metadata and Hasura for everything else. That said, I've never used Hasura so I can't exactly tell.


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


I'm rather worried about having a large table being able to accommodate for any custom object than the fact it is multi-tenant, we could shard by tenant_id quite easily.

I might be missing your point and I'm far from being a database expert. Would you give me more details about what challenge you have in mind?


An index on all 500 fields!


Congrats on the launch! JFYI, app. and docs.twenty.com are both showing cloudflare origin errors at present.

The signup from the main site asked me to message on WhatsApp, which I don't use, so I backed out from signing up.


Sorry about that, not sure if it's the HN trafic that crashed the server or something else. We're looking into it. The signup is on app.twenty.com and hopefully it should be back soon, I'll reply to this post when it is


OK it should be back now


This is disqualifying, for me. I tried to view the CRM and it asked me to log in. There are a lot of dark patterns just at first blush that make this feel spammy.


Sorry about this. Our focus for this launch was the Github repo / local setup, I should have made that more clear. We haven't launched to non-developer audience yet, that's why our marketing website redirects to a waiting list. If you want to try the app quickly you can just go to app.twenty.com and put a fake email address if you don't want to give yours. The signup is quick.


I just want you to know that I appreciate you coming in here an addressing people's comments. HN is a tough crowd, so don't take it too personally.


https://app.twenty.com/ just gives me a blank page right now in multiple browsers.


Sorry. It was down a few minutes ago but should be back now? Could you trying clearing the cache (cmd + shift + r)?


Yes, that worked, and I was able to get in with a throwaway email.


The auth popup also breaks the back button which also is pretty crappy.


Thanks for letting us know, I've logged an issue, we'll fix that this week or next week. https://github.com/twentyhq/twenty/issues/763


Looks neat iFelix!

I'm interested to know how much time you've actually spent using CRMs or ERPs yourself. Not clicking around and exploring features, but actually using for something.

While I know this is a very early release, my biggest concern is naivety about real world usage requirements, and if you'll be able to manage the feature creep that will be coming with it without just turning into another Salesforce or NetSuite.

As soon as you get users it's going to get harder to add in those things you're putting off thinking about until later, and managing it will become a legacy suckfest. This manifests itself in a slow, slow, slow experience and necessary UX decisions that make the user scratch their head.

I'd say the biggest example of this is custom fields. It's not just another problem to solve at some point, it's probably one of the biggest ruins of CRMs.


Your question is right on spot. We are three founders with a passion for design (1 designer + 2 ex-Airbnb were design was key to the culture), building this product 2 decades after Salesforce when the tech is different, so we will approach problems with different priorities and ways of thinking than Salesforce did. But there is definitely some naivety and some challenge ahead of us, as none us is an expert ERP/CRM user. We'll be very careful making design decisions on structural elements like like custom fields yes!


You should spend some time with sales leaders to better understand what's needed from a CRM.

I took a look at your CRM product and understand that your long term goal is a great ecosystem...however, your UI is missing the point of a modern CRM.

A CRM used to be account/contact/opportunity tracking. Now, sales teams use CRM as the de facto customer-focused data warehouse (because no one in sales actually knows how to query a data warehouse). These days I rarely use salesforce for anything besides looking up data that was written there by another sales tool via the API. The product focus should be on developing a great analytics solution for salespeople, not an online Rolodex.

I used to work at Salesforce and have deployed it at multiple startups as the founding head of sales. Shoot me an email if you want to talk more; I'm looking forward to the day that Salesforce is replaced by something that better fits the modern sales process.


As a daily Salesforce user for a decade I'm happy to rant about everything salesforce does wrong from an admin and end user perspective.


The biggest mistake a competitor can make is thinking Salesforce is a CRM. They may sell themselves as one, but that is just to get a foothold in a company's sales system. Salesforce actually sells (1) an ecosystem that lets your company connect to any other software out there and (2) a platform on which you can build...basically anything. These two together ensure that every one of their customers is 100% locked in and will continue to pay whatever Salesforce asks for all eternity. The actual CRM part (basically tables of data with a UI) is trivial, and not really their "special sauce" that you can disrupt with something shinier.


100% agree. And we are not there yet. But I feel like open source is the best answer to 1 (building an ecosystem of integrations), and that it will also allow us to build a better platform for developers (2): why learn Aura components/Apex when you already know and can use Typescript/React?


An open-source core is only part of it, because different users will need different data models for different business domains. One of the biggest challenges here will be: how can you allow tenants to run arbitrary plugins that (a) execute arbitrary sandboxed server-side code, and (b) can store arbitrary new data models and custom fields within your instance's centralized storage alongside the canonical model types, in a way that allows for indices, foreign key constraints, and derived materialized fields?

If you solve this and provide a great developer experience, including free sandbox accounts and a payments stack so that developers can sell plugins without needing to ever operate their own infrastructure, with namespacing to avoid compatibility problems between apps, then the ecosystem will come.


That's a very good point. In the early stage, we were thinking about a single tenant architecture which would make this questions way easier. However, I am a strong believer in multi-tenant architectures as they allow to scale while mutualizing the resources (I personally think it's single tenant at scale is non-sense in term of ecology) and we will invest into maintaining a multi-tenant architecture.

So, as we go through the multi-tenant path, what you say is very relevant and will be challenging.

Regarding custom entities and custom fields, we plan to introduce a flexible data table backed by a meta-data, quite close to what salesforce is doing ; this article is gold about how they built it: https://architect.salesforce.com/fundamentals/platform-multi.... In short, you have a data table (uuid, objectid, tenantid, field1, ..., fiel500) where fields are VARCHARs and you build your own engine on top of that. This comes with a lot of challenges such as performances (indexation), typing (we lose Typescript/GraphQL power obviously as we deal with flexible data modeling)

Regarding plugins that we want users to be able to create and to activate on the marketplace without vetting, here is the way we see it right now:

1) Front-end: serve a dedicated JS depending on what workspace you are on. Rebuild this JS when you activate / update a plugin

2) Back-end: we will need to execute the code in a separate environment. We were thinking about serverless lambdas for the cloud version and keep it local on the main server for self-hosting ; kind of allowing two drivers (lambdas + local) to execute plugin code in the codebase but using lambdas only on the the cloud).

Would love to chat a bit more about it. We will likely open a Github discussion thread in the upcoming weeks about this specific topic) so we can get the feedback from anyone interested into it


>However, I am a strong believer in multi-tenant architectures as they allow to scale while mutualizing the resources (I personally think it's single tenant at scale is non-sense in term of ecology) and we will invest into maintaining a multi-tenant architecture.

Our products use multi-tenant architecture in the form of 1 database file per company, and a single database server for everyone (by default). It's great for data isolation, as we can't accidentally leak sensitive corporate data from one company's account to another (say, a missing WHERE). It's also great for indexing, as DB queries only touch small subsets of data. And it works well for most businesses (10-100 employees). For large companies (not that many of them), if we detect a lot of activity which stresses the main database server, we have infrastructure in place to migrate them to dedicated servers, transparently to users. It's worked pretty well so far.


Very interesting, this makes sense, it is definitely a direction we could go into. We are using Postgres and were also considering using 1 schema per tenant.


HubSpot recently launched something to do this by providing a Lambda runtime to generate components within the CRM dashboard.

https://developers.hubspot.com/docs/cms/data/serverless-func...


+1, thanks for the link


We built a version of this which goes far further.

- Monaco (embedded VScode inside the target app/platform)

- Typescript

- NPM modules

- Linting/autocomplete including custom fields/objects, so you basically know it's going to work before you even run it

- breakpoint debugging

- Version control with diff view

- Magic utilities to call the platform's own APIs in an easy typesafe way

The breakpoint debugging provides an amazing experience for the embedding app. It's pretty magic. But because the runtimes like Lambda don't ship the Inspector API we had to create a custom compiler to make it work.

We are actively looking to license this stack to other SaaS looking to build platforms.

If you want a demo leave your email and I'll reach out.


The ecosystem is really not about Aura/Apex. I think the API is a bigger piece. Pretty much everything in Salesforce can be controlled via the API.

That isn't even the big challenge though. The biggest challenge is getting people to build for your platform. If a sales team uses 10+ integrations (it's honestly probably 20-50), then they will pick a platform that supports 9-10 of their integrations.


A "real" development stack might enable users to build actually good experiences. The custom (proprietary) stacks I've seen so far have always been pretty "meh", lacking features, community and tooling, resulting in not-great DX and making building some features something between very hacky and impossible.


Accurate. The licensing (and the "kill switch") at a previous job were controlled entirely via Salesforce. Our app would "phone home" regularly to check which features are being paid for and we'd toggle them on and off in our app accordingly.

I had, at the same company, been asked to evaluate building Salesforce apps (using the custom programming language they provide) and contrasting that with building new apps on our own metadata-driven platform.

Developers hate it, business people love it. It won't be going away for lack of paying customers, that's for sure.


Apex is nightmare fuel


100% - having to submit code server side to just get compilation results is the worst development loop I've ever experienced.


I'm really eager to get to the point where we can work on CRM extensibility and developer experience. We're hoping to bring traditional web development workflows and not re-invent anything. We opted for a multi-tenant infrastructure for the cloud hosted version so there will be some additional challenges to make it work in that context!


If you wanna see what that might look like, take a look at servicenow, I do basically all my coding in vscode, and ctrl+s saves to the dev server. they have one of the more robust developer environments I've used.


great thanks for the tip, we'll try it!


> The actual CRM part (basically tables of data with a UI) is trivial

Although I agree with the general sentiment, I disagree with this. I've tried out over 100 low-code ui builder over the past year (including creatio,Corteza,ERPNext,Baserow,tadabase,appsmith,nocodb,mathesar,bubble, etc.) and so far none of them have perfected "excel like ease with the power of a database".

If anyone has any suggestions, (that's not on my list https://docs.google.com/spreadsheets/d/15Pg6y11JscBMK-PK06f7... ), please let me know!


2 competitors which I think are getting things right on the UI front are Attio [1] and Folk [2]. It's not as powerful as Salesforce and the data structure is very loose, but they have done a good job with the user-experience. They are not open source though.

[1] https://attio.com [2] https://www.folk.app


It looks like a near clone of what Attio is doing.


The trendsetter here is Notion, not Attio


One of my requirements is that I must be able to host the database myself :-) (with a preference for Postgres)


No one’s going to sell you just a UI


You seem to be missing Coda ( https://coda.io ) which (in my experience) comes remarkably close to “Excel with data powers”. Think of Notion’s document editing and tables, but with _much_ more power, a proper formula language, UI widgets, etc. The Coda team have churned out a ton of amazing features in remarkably short time. The main drawback I’ve encountered: no obvious way to separate code and data. I can’t find a way to version/clone one without the other while keeping the data in Coda. However there are plenty of integrations with external data sources, so keeping a chunk of the data external may be the best way.

EDIT: Oops, forgot to thank you for creating this amazingly comprehensive sheet. I’m looking for a similar thing myself: a self-hostable CRM for a small team that wants some flexibility around custom fields and automation but doesn’t need most of the other common CRM features. My current plan is to try AppSmith, but there are a bunch of entries in your sheet that I haven’t seen before. Thanks again!


Also missing these app builders, both of which are open source but offer managed hosting:

* Budibase https://budibase.com * ToolJet https://www.tooljet.com

They’re both more of the AppSmith/Retool sort of thing than Excel, but may be worth a look anyway.


FWIW, Budibase also has it's own multiplayer database that allows users to build workflows akin to Airtable.

I'm the cofounder of Budibase.


and https://windmill.dev


Check out https://lowdefy.com

We’ve built Lowdefy as a config webstack. Making it really easy to build web apps with yaml or json. You can also extend with npm plugins.

Lowdefy is more low level than a crm. But we’ve used it to build advanced CRMs for enterprises.


Replace Salesforce and CRM with ServiceNow and ITSM and it's a similar story. They call it "Land and Expand". There's a reason they have a 99% or so renewal rate.


ServiceNow can't be worse than BMC Remedy... I hope.


I think of Salesforce like an octopus that puts immovable tentacles into the organisation that are almost never removed. It provides as much opportunity to be misused as possible!


The question is why are they so successful in doing this. Why do organizations by default use Salesforce.

I have never used nor worked at an organization that is built on top of Salesforce.

Just a regular web dev.


The basic answer is that when an certain type of organization gets to a certain size, they hire professional full-time sales people, and those sales people have been trained their whole career on Salesforce, so that's what they're familiar with and that's what they're going to want to use.

I've tried twice to buck this trend at small startups. I was successful in getting the companies to use a lightweight, elegant, user-friendly, not-Salesforce CRM system when they were small (<10 people). And everyone was happy. And in both cases, as soon as the organization got large enough that the professional sales people came on board, they said "what is this garbage where is my Salesforce", and that was that.

This is a VERY hard pattern to break, unfortunately.


I did the same thing. Then the lightweight, elegant, user-friendly, not-Salesforce CRM system that I had convinced the company to depend on (Highrise CRM) was mothballed by 37 Signals. Yes it's possible to export data, but there are usually things that we couldn't export (like notes and files/attachments) and it was a nightmare I will forever avoid at all costs.

After another client found that their Batchbook CRM solution was also being EOL'd, I started to feel like going for the biggest most well-known market-leading CRMs ends up being a good choice just from the point-of-view of data longevity and peace of mind.

I really wish 37 Signals open-sourced Highrise, or that CiviCRM or any of the other open source CRMs managed to get to a level of polish and ease of use so that I could ditch Salesforce, but I've yet to find anything that could justify such a move away from the Salesforce behemoth.


| I was successful in getting the companies to use a lightweight, elegant, user-friendly, not-Salesforce CRM

Can you please name these softwares?


Nutshell CRM (https://www.nutshell.com/) is my fav for sales teams. Some of our younger sales staff have also pointed us towards Less Annoying CRM (https://www.lessannoyingcrm.com/) and Zendesk Sell (https://www.zendesk.com/sell/)


It is the React of sales!


> I have never used nor worked at an organization that is built on top of Salesforce.

You probably do. Salesforce has all kinds of different products from Slack to Mulesoft and Tableau. Salesforce starts their pipeline by solving one problem, making that work well from a business ROI perspective, and then they pitch you on another and another and another with package pricing. This is basically the Oracle model and how Larry got his blood money.


Benioff started his career at Oracle and was a prodigy there - becoming the youngest ever VP or something like that. It's not surprising if his playbook is inspired by Larry's.


Oh yes. I definitely use WorkDay. Interesting, never knew WorkDay is created by Salesforce.

We are a very M$ bias company, hence, no slack.


Workday isn't owned by Salesforce.


That was my fault, I don't know why I thought that, but they got it from me.


Workday is not Salesforce. The rest, yes.


You're right! My mistake.


Salesforce is basically the OS for your company.


What's SAP then?


Same thing, as is servicenow, they're all cloud platforms angling to be the "Company OS" all coming at it from different angles. Salesforce comes in at the sales side of things, SAP invades as a finance app, and ServiceNow begins their encroachment as an IT ticketing system, but they all wanna be THE only cloud platform your company needs.


good to know what these "Company OS" stands for

> Salesforce comes in at the sales side of things,

> SAP invades as a finance app, and

> ServiceNow begins their encroachment as an IT ticketing system,

but they all wanna be THE only cloud platform your company needs.


Good summary!

And Microsoft through the Productivity apps? (Word, Excel...)


Sure but Microsoft isn’t really offering a coherent solution for general company data and processes. They have the power platform, but because there’s no happy path, best practices, laid out it requires a lot more buy in from actual engineers who don’t have a lot of love for nocode platforms.

It’s totally feasible to build a IT ticketing system in power platform. And then to build a sales/CRM solution and then also build a bunch of analytics and compliance and such for finance, but because Microsoft doesn’t have the barebones platforms there it’s a lot more work to stand up, and you end up maintaining a very custom product that is totally dependent on Microsoft not suddenly changing their pricing or deciding to kill the platform due to lack of revenue. At that point you may as well just build your own thing in actual cloud products instead of depending on the “baby proofed cloud”.


> Sure but Microsoft isn’t really offering a coherent solution for general company data and processes.

Do you have a moment to talk about our Lord and Savior Dynamics 365?

> Microsoft Dynamics 365 is a product line of enterprise resource planning (ERP) and customer relationship management (CRM) intelligent business applications

https://en.m.wikipedia.org/wiki/Microsoft_Dynamics_365


On a related note, what happened to BizTalk?


What? Microsoft is one of the biggest players in the market in this space with Dynamics 365!

I don’t have any data to back it up officially, but working in the space it seems like dynamics is taking customers from their competitors (eg SAP) fast too…


Microsoft also has Dynamics 365 (née Navision).


D365 has elements descended from Dynamics CRM, Dynamics AX, Dynamics NAV and probably lots of other stuff!


> and probably lots of other stuff!

Yeah, lots of botched React integrations, misuse of Serviced Workers, nightmare security roles, just to name a few daily problems you will run into when choosing Dynamics 365!


It seems like a good solution would have clean interfaces between various pieces so they can be easily replaced. Sales, purchasing, payroll, HR, and IT stand out to me, but there may well be others.


A virus


An OS for bleeding companies dry


An OS for Finance :)


You can say the same thing (lock in) about any product that has migration costs. If everybody thought that way nothing would get built. I say to Felix: just do it, but think about these problems.

Fortunately there is a whole field of business devoted to this problem: go-to-market strategy. Target a niche, offer a compatible product, offer a significantly better product, offer a different product, offer a cheaper product ... the options are endless.


> You can say the same thing (lock in) about any product that has migration costs. If everybody thought that way nothing would get built.

Not all "migration costs" are the same: to quote General Turgidson, "It is necessary now to make a choice, to choose between two admittedly regrettable, but nevertheless distinguishable, postwar environments: one where you got twenty million people killed, and the other where you got a hundred and fifty million people killed."

In the case of software migration costs, the cost of migrating away from a proprietary application-platform with zero-to-little code and data portability, will be orders of magnitude higher than the cost of migrating away from a proprietary infrastructure-as-a-service platform.

This isn't anything new: while Cloud-y platforms like SalesForce present even higher barriers to exercising our rights to data-sovereignty than what we had previously with SAP (because at least with SAP you can defenestrate the machines), it's all too similar to the 4GL vs. SQL wars of the 1990s. I honestly can't think of any orgs from then that regrets betting on a SQL-based RDBMS, while there are still companies out there depending on FoxPro, Progress, or worse...

This is also why I flat-out refuse to use Firebase.

Another hidden-cost of 4GL-like systems is that eventually they run-out-of-steam: hype fades and the vendor becomes stagnant and/or can't attract the best minds in the industry to design and build the platforms they expect others to use, so they lose whatever advantages they might have had which justified their proprietary nature - or an even more insidious version, whereby too many slow-moving companies become dependent on a particular platform that the platform's vendors have to intentionally hold-back the platform to avoid imposing too many fast-moving potentially breaking-changes (Java comes to mind...).


> This is also why I flat-out refuse to use Firebase.

I'm glad to see I'm not the only one with a long memory.

Or maybe that's better described as PTSD.


Right, but the bigger the organization, the larger those costs. Think of a city of Los Angeles switching to a new system for tracking their public works department versus a township of 3,000 people. Smaller orgs are much more tolerant to this. New orgs start small and don't need something huge like Salesforce immediately; they need something usable.


The salesforce object model/API is actually pretty reasonable and easy to work with. Their UI is horrible but the Lightning version is fast at least.


I feel like people don't appreciate enough that Salesforce is selling a... Smalltalk OS that everyone shares access to. It's nifty!


How is it like Smalltalk?


There’s a lot of introspection tools within the UI, pointing you to implementations. The code management is happening “within the system”, so to speak. There’s just a lot of “everything is within this system and is inspectable”


It's more than that. If you look around the market at any sort of data, BI marketing automation, payments or a dozen other verticals and every single one of them will have a first-class integration with Salesforce extolled on their homepage. A business running Salesforce is like a business that speaks English.


"The biggest mistake a competitor can make is thinking Salesforce is a CRM"

A lot of CRMs seem to evolve into general purpose platforms - Salesforce and MS Dynamics being the ones I am familiar with.


I love this! Having been the “Salesforce guy” at a few companies, it’s good to see people working to solve those problems.

As a developer, I’m eager to have a solution that limits sales teams constructively. The ability to add, edit, and delete fields and properties on the fly made creating maintainable client software difficult.

It will be cool to see how you go about it!


Thanks! We plan to add custom fields in August. Super interesting feedback. There's indeed a balance to strike between: - easy to configure by everyone which ends up in a mess - full config-as-code and developers become a bottleneck Hasura is an example of an app that started as UI-driven and I feel is becoming more code-driven. Probably a frequent natural path as product evolve and move from SMB to Enterprise. Since the CRM buyer is often the Head of Sales, we'll have to be smart to sell them the more restrictive path!


My team develops our company's own homegrown internal CRM. It manages basically everything about the company, and contacts themselves is a very tiny part: there're marketing campaigns, followups, accounting, incoming/outcoming calls management, our products' entire licensing/subscription system (neatly integrated into everything else), tech support, inbox/outbox, activities, contacts, leads/lead events, analytics, the backend of the shopping cart on the site (products, pricing, discounts), the reseller portal, integrations with various vendors including payment systems, A/B testing etc. -- to name a few, off top of my head.

Before me, there was an attempt to migrate to Dynamics CRM but our current CRM we've being developing for 15 years has so many custom rules/quirks/etc. eventually they abandoned the attempt because of the huge scope and the difficulty to reimplement millions of lines of custom logic in a proprietary CRM.

Before I joined the team, the CRM's development didn't follow best practices and now it's very hard to maintain and update, due to architectural problems aka "big ball of mud". Another issue is that it was not designed to be extendable, every small rule the business comes up with is hardcoded in the code, and so there's no way to configure things somewhere in the UI with least amount code possible.

So if I was to migrate our CRM to an open source engine/core, the following is a list of things I would want to see:

1) good modular internal design/API so that it was possible to easily add custom complex logic/flows

2) design/API which is extendable and doesn't have hardcoded logic/doesn't assume your company's flows

3) allows to configure as much as possible from the UI

4) an ecosystem of plugins/some sort of marketplace, with, again, solid, standardized API


Thank you for the feedback. What you said resonates with me a lot.

Standardized APIs:

While we are designing Twenty, we have in mind to provide three APIs: a GraphQL API (headless), a Front-end React API and a NodeJS API that engineers could use to build their own plugins. We imagine that you could build your plugins in your own repository using SDKs maintained by Twenty. Then on your twenty instance you would be able to install a plugin from your custom repository or a shared marketplace (this would maybe imply a vetting process) There are many challenges around that, especially in resources monitoring and security given we are going into the multitenant architecture

API that don't assume custom business logic: Here, we might have a slightly different opinion: we think that Twenty should come by default with a quite opinionated behavior. We will likely introduce a rich library of standards objects and fields that would have pre-defined behaviors. However, we would also enable the users to create custom objects and custom fields if they need that can be customized in whatever makes sense for their business. So: Standard objects/fields + Custom object/fields. We don't know yet if they share the exact same API


>Here, we might have a slightly different opinion: we think that Twenty should come by default with a quite opinionated behavior

It's perfectly fine to have opinionated behavior as long as there's a way to override it. Companies which don't have 15 years of tech debt have to start from somewhere, and it's nice to have good defaults.


> We’re very eager to get your feedback

I love the total lack of the Material UI!

That being said, can you please make columns in tables to be resizable and the dividing lines between table rows a bit more visible?


Thanks! Resizable columns and higher contrasts are on their ways.


My 2 cents as a founder evaluating CRMs.

I would prefer to not use Salesforce until I have to - I know it's expensive, slow, and hard to customize. At the same SF users who I know tell me that nothing else works for orgs of above 100 people.

The demo looks great and I like that you are focusing on UX and performance - I would expect Linear-like experience for a tool I use every day. I would prefer a hosted version (my experience with self-hosted analytics/business tools was a nightmare).


I 2nd this, minus Salesforce being hard to customize. It's probably too customizable.

At a certain stage of a company, sales reps expect Salesforce. So much so, that even when we finally caved and got it, I had reps specifically turn off Lightning and stick with Classic mode. It's like Bloomberg - it's what they know and can move fast in.

As much as it pains me to say this, it may make sense to have an option that can mirror the Salesforce UI vs reinventing the wheel. Or maybe even an integration / escape hatch to migrate everything off of Salesforce to this. Basically, if you want reps to adopt it, make it close as possible to what they know.


In terms of UI, Notion has been our main source of inspiration. Targeting the bucket of Salespeople who enjoy the Notion UI is definitely a smaller one than those who know how to use Salesforce, but I feel like it might be a faster-growing one. It's a good point that it will become harder as we move to larger companies with a higher share of experienced sales reps that don't want to change.


Good points thank you. Right now we are starting to work with companies in our YC batch which have relatively simple needs, probably like yours (founders doing sales, less than 1000 contacts, etc.). Our goal is to deliver fast enough so that these companies never outgrow us and have to switch. Not saying it will be easy to keep that pace given the breadth of features/integrations that becomes required as you grow, but we'll do our best!


this is brilliant (and great name). The true value of a salesorce/hubspot killer CRM is integrations. Most people use hubspot or salesforce just as a database and use a bunch of other tools.

If you want to do one thing - focus on integrations first and UI second. Let your integration architecture inform your UI/metadata driven architecture.

the good thing is - this is an easy step into monetization. Anyone would pay the same cost as hubspot for an opensource alternative...but with the same integrations. Managing the data pipelines is the hard part.


Yes that's exactly what we've seen! A lot of companies we've talked with don't have a datawarehouse / reverse-ETL, so they use the CRM for that instead,and the integrations are core the CRM value prop. That's what makes it hard for small CRMs with a nice UI to compete with large players. From that perspective, I think being open source will help us a lot build this network of integrations faster

Great feedback that we should prioritize it as early as possible, thanks!


so its not just about data warehousey stuff.

Take Apollo.io for example. Its used for lead gen. Most people will instantly drop any CRM that doesnt integrate with Apollo.io and move leads (e.g. https://knowledge.apollo.io/hc/en-us/articles/4416619021837-...)

Same with scheduling - if the CRM doesnt integrate with Chilipiper or Calendly, its most likely an insta drop.

Zapier can be used, but why bother ?


I worked on a "Salesforce killer" that was actually meant to make Salesforce stronger by fixing its biggest known problem: that sales people hate using it. Our goal was to let sales people send text messages, which we would then use NLP to interpret correctly, and then add to salesforce. A sales person might sell a million bottles of shampoo to Hilton Hotels, then she might get in her car and drive home, on the way home she could talk to her phone, using voice-to-text to create the text message that would go to us. We would then use NLP to convert that text to appropriate objects and actions in Salesforce. The idea is that no sales person would ever again have to log into to Salesforce.

Of course, the leadership of the startup was a complete disaster, and the startup ended as a disaster, so we were never able to fulfill the potential of that vision, but I do think the future must involve NLP technology that allows sales people to talk to CRMs.

For anyone interested, I wrote a fairly popular book about this misadventure, How To Destroy A Tech Startup In Three Easy Steps:

https://www.amazon.com/Destroy-Tech-Startup-Three-Steps-eboo...


I may have too limited an imagination, but using NLP to interact with a computer UI is a Very Hard Problem. To me it feels like the old joke you know, 1 - Use NLP to interact with SalesForce competitor. 2 - something something. 3 - profit! Apologies in advance for the snark, I'm really curious.

I mean, how much time would be really saved by talking to the phone vs more traditional inputs? Is it the dictaction which saves most time? If not, what is?


It’s the advantage (like they said) that you don’t have to login into Salesforce. This tool slows them down, and via voice they don’t have to use the salesforce application directly. Imagine you have awesome ideas and plans and have 8 hours a day. But if you can only be productive for ~6, you’re losing a ton of time just because the tool is bad designed/planed/slow/{insert more words here}.

If you want more about that, I would recommend reading the book. Quite interesting read :).


I just feel that "via voice" is what makes me having doubts. Almost any tool could be adapted to a "via voice" interface, but which tools will become better for it?

I have a hunch that almost any custom interface on top of Salesforce would improve it.


Yes, I guess that’s the thing. The custom interface would be voice commands then.


And if a voice interface is a great improvement, how much of that is because a voice interface is a good choice for this application, and how much is because Salesforce sucks.


I wonder how much of that could be solved by Siri + Shortcuts (+ Salesforce)


It is still a good goal. Having to input details into forms is why even the most user-friendly CRMs can still not be enough to get staff to use them. Unless you work in a trendy youngish hipster startup, most companies outside of that bubble have the constant challenge of getting employees to use new tools. I have a client company whose employees only use WhatsApp and email, barely use OneDrive and resist using Slack or Salesforce or any other tools.

If they could just dictate a note and a contact record in Salesforce gets updated, and it does so with near 100% reliability, that would definitely be a game changer.


Yes, I also think logging calls/meetings will become a thing of the past with LLMs and good integrations.


I worked as an implementation consultant during the 1st or 2nd generation of CRM apps back in the fist decade of this century. Then, since 2010 I became a CRM end-user, mainly of Salesforce.

After all those years listening to sales people complain about workflows and broken UI/UX, I realized the perfect system for this type of user is a message driven minimal UI app.

System would send email/IM to users all day long asking questions about news leads, changes in opps stages, phone calls, contracts sent for signature etc. Sales folks would click a link, fill in a 2 field form and hit save. Call that "micro updates", if you will. The system mimics the sales manager who nudges the sales person for updates. Navigation within the app is minimal, so there is no room for alibis like: "Oh, I'm not updating it because it takes too much of my time. I was doing sales work instead."

All this would be for the operational CRM. Analytical/management parts of the system would present the typical UI/UX we all know about.


I feel like that covers half the story. The system should be smart enough not to poll users, but push queries if it detects changes to persistent data. For example, if some sales employee took a call from a previously-unknown number, gather as much data as possible (call metadata, documents modified during and after the call, content touched by the sales guy) and only then query them for new lead information.

What I'd like to see is an actually smart system that interfaces with data in my company, connects the dots intelligently and prompts humans for input where it requires it.


Interesting! Hubspot launched a chat interface[1] but it doesn't have that component you describe where it pro-actively asks you for things.

I think logging will eventually become much less painful than it is today with good integrations and LLM, most of it could be done automatically.

[1] https://chatspot.ai/


Update: Kommo.com seems to be aligned with the idea to be message driven having integrations with WhatsApp and Telegram (among others).


"message driven minimal UI app"

Via Slack/Teams/WhatsApp?


I don't know about Teams. To me, it is more like a web conferencing tool. In case of Slack and WhatsApp, yes, they would be perfect channels to push the update requests for the sales teams. IMHO.


I think your open source story is weak. Your narrative is we shatter build vs buy. CRM in today's day and age is mostly buy decision. If you want custom analytics or workflows, you would hook up various point-solutions like segment, hightouch and various business automation tools.

Also, it is not very clear which market segment you are going after. If it is midmarket then my narrative is kind of what happens there. In early stage you have low ticket size problem. In enterprise, you have hubspot, salesforce and various other tools.

Building a salesforce knock off does not make sense. As you said, `The startup world is littered with ghosts of so-called "Salesforce killers"`, there must be a reason why. Most likely , it is the fact that there is no market for salesforce killers.

I think your pricing is off. It is $30 per user per month, Post 50 users, your platform is more expensive than hubspot's CRM suite which includes everything.


We are currently evaluating CRM packages. This is probably a bit too in development for me to recommend but I'll let you know our internal requirements so you have one extra data point in the market.

Phone integration is huge for us. We need the CRM to respond to an incoming call by bringing up the contacts details if it recognises the number. We also need a log that the cal began, was answered by, and how long it lasted. If we could do that on cell phones it would be amazing.

The next thing would be ecommerce integration followed by integration with our accounting system. Both need to feed contacts and contact details into the CRM. What have they ordered, how much have they spent. What are their payment terms.

After that it's all just notes.

Oh, and we would need SLAs with good up time and data protection.


What type of phone integration would you need? Do you use an external provider like Aircall? If you don't, I know Close.com has a built-in phone functionality so maybe their solution could fit your need?

We definitely need to work on integrations soon!


We have a dated IP PABX. But would happily switch to another system to enable a new CMS. Thanks for the mention of close.com.

As far as integrations go, for us it's an API that is critical. Our accounting system is Myob Exonet. So old that nothing integrates but it was an API so we can write an ETL process to dump data out of it into a CRM. Our Ecommerce platform is NopCommerce but that's a bit obscure and so heavily customized out of the box integration plugins aren't going to work.

Also $29 per seat per month is an amazing price. But I've noticed something strange with mentioning pricing to upper management.

If I take say Zoho CRM, one we've looked at. The plan we need is $55 AUD per seat per month. Realistically we're going to have 5 - 10 users of the system so that works out to $3,300 - $6,600 per year.

I can get $6,600 per year for CRM operations approved no problem. But, If I say $600 per user per year management freak out. It's the same number but there is something about per user that worries upper management.

Now I always just give them the per year 10 user cost and say if we keep under 10 sale and support staff this is the cost.

I don't know if that is unique to my company but if it's not some pricing packages with yearly figures might help sell. That is true over all SAAS products we use.


Thanks a lot for sharing this precious experience. Do you like what Close is doing for instance? https://www.close.com/pricing


Yeah that does help. Packages of users draws the attention away from the per user pricing model. I don't know why but they just don't like it. Even if the numbers are the same.


You should evaluate close.com if not already. They have all the features you mentioned. We use them for sales for our business.


Close.com is already a great source of inspiration for their opinionated approach. We hope we can make the difference on UX in the short run and that community will bring much value for every user in the mid-run.


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 just a CRM.


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.


I've been tempted to do something similar over the years. I've worked with Salesforce quite a bit, and I dislike almost everything about it.

I settled on doing open source company data: https://news.ycombinator.com/item?id=35977057. I think an open source CRM with the all the world's companies could be pretty killer.

I created an account and will play around with it. Pretty cool so far.


Nice! Agree this could be great. Is this hosted as an API somewhere?


Congrats on launch! I completely agree with the wisdom of launching early as soon as some basic functionality works. If I had to suggest the lowest-hanging fruits for your roadmap, it would be email automation and lead enrichment.

I'm an engineering consultant for various sales tech startups which operate within the ecosystem of "build a HubSpot/Salesforce/Freshworks/etc integration for a specific type of sales organization". What I would love to see in an open-source CRM is an easy way to bring these integrations directly into the CRM - imagine a `crm.json` file which configures a CRM web app and imports custom code modules from a central repository, similar to `package.json` and NPM.

A big issue end users bring up with Salesforce/HubSpot is the high cost, especially for sales organizations which only need the core features you have in your demo today (track leads, deals, companies, etc) but have to buy a seat for each salesperson. A managed service for a hosted CRM without feature/usage/seat limitations would be an easy sell if you can reliably ingest existing CRM data and provide some level of integrations/customization.


I like the "crm.json" image. We definitely want to work on doing something modular like this.

I also wanted to price differently than by seat initially. Because CRMs tends to be the source of truth for the whole organizations, and usually teams like customer support are left out because it's not worth paying a license for them to just read the information the sales have put in, while it would be useful. But we didn't find a better way to price in the end. Pricing by usage feels off since there is no cost associated to usage (a user that logs more activities is not going to cost us more). How would you charge then?

Noted for email automation / lead enrichment!


If you look at medical EMRs (essentially a CRM where patients are customers and salespeople are doctors) there is a similar situation as the CRM market, where a few big players dominate the scene with crappy software and feature creep (i.e. Epic = Salesforce). Based on the clean UI you have so far, you're definitely on the way to building a better user experience for CRMs, but at the end of the day you have to sell this to a salesperson, just like people selling better EMRs have to sell to hospital administrators who don't care how great the code is.

Consider an organization spending $10k/year on HubSpot. They're also spending at least a million a year on salaries/commissions for their sales staff. Optimizing software costs addresses 1% of the total spend, while making sales people more efficient optimizes the other 99%. In general, if your target customer is sales management, I would pitch support/customization contracts to streamline sales organizations when you're picking up initial customers. This would also likely bring you perspective on the wide range of customizations out there.


My two cents based on how we use Salesforce

1- being able to bcc or better yet have a gmail extension to log emails sent to prospects and clients is a foundational requirement for us. Be sure to have that asap. Outside of being a CRM, our SF is the knowledge base of all customer interaction.

2- Opportunities and funnel management are critical workflows for us. Being able to define rules on qualification and auto activate / expire a prospect is important.

3- documentation is important. I know there are armies of SF consultants I can tap into if needed. In the absence of that, a strong wiki will be important as you start offering customization

4- speed speed speed. My team much preferred SF classic over lightening because it was significantly faster

5- for us, mobile is overrated. Most work is done on the laptop or desktop. Mobile is more about reading details and freshening up on client ahead of the meeting

Lastly, I’ve dabbled with the idea of offering a light-weight CRM to our clients (we serve a niche industry that has onerous onboarding requirements and the vast majority of clients don’t use an off the shelf CRM). Once you polish this off, if you’re open to chatting about a white labeled solution feel free to connect.

Good luck.


Thanks! 1 - We should have that soon yes 2 - Auto-activate would be based on what kind of trigger? 3 - We'll work on that and creating a strong community 4 - Good to know it's also a customer priority and not just dev obsession! 5 - Good to know 6 - Our current license is AGPL which might not be ideal for this but we are very open to chat and adapt. We'll focus on building strong foundations in the next few months but once we have that, this would be a great use-case. My previous company was in a similar situation (in the property management industry) and I ended up building an in-house CRM for our partners. I probably wouldn't have done it this way if there was a good/extensible/open source solution available. My email is felix [at] twenty.com if you ever want to get in touch


I did a CRM bake off for a startup about 5 years ago.

It is a super crowded market, probably the most crowded SaaS market in the world.

There are even a half dozen open source CRMs.

Good luck.


Just as food for thought, the two big problems I see with every single Salesforce deployment are:

1. Excessive customization. Ever seen a Lead record with fewer than 300 custom fields? I haven't! I have no idea what you do about this from a tool design standpoint but... think about it. It's a huge problem.

2. Synchronization. If you have Your System, and then you adopt a CRM, now you have state in two places. And commonly that state is allowed to mutate in both places, and now you inhabit a permanent nightmare hellscape. Figure out how to discourage this. Think about ways of modeling relationships to outside systems (ala NetSuite's externalId) and enforcing unique connections. Make it easy to request supplementary data "live" so that there's less reason to copy it in.

Good luck!


Congrats on launching! Great tool, love the minimal UI and the "coming soon" features

I've used CRMs for the last 10 years, starting with an internal built CRM for a bank that I worked at and moving on to the salesforce, hubspot etc..

Here's what I've noticed being a user/developer - Users will always complain! If it takes more than 2 minutes to get something done they'd rather not do it

- All CRMs have a learning curve, once users get used to the workflows they're comfortable with, they don't want anything to change. (e.g. when one of the CRMs relaunched with a new UI, a few users refused to use it for a long time)

- Users prefer the work done for them, no one wants to spend time thinking. If you have a library of pre-built workflows it goes a long way. Even better, do all the analysis and let users make a binary decision

This is one space that really interests me, let me know if you wanted to chat. My twitter is in my bio


Betting on user's laziness is usually a good path! I mentioned it in another comment but I think the way we log activities is something that will evolve a lot with good connectors and LLMs. And once you have the right data logged you can think about suggesting the next tasks, performing actions on behalf of the user, etc.

I've followed you on Twitter!


> 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.


Could you elaborate on where this sits between a custom Airtable/Notion CRM and something more purpose built like Wobaka, Attio, Folk, LessAnnoyingCRM?

Both focus and solve CRM issues for smaller companies. Would love to hear three main items:

1) Which company profile (size, revenue, industry/use-case, etc) is Twenty best suited for and which of the above do you has at the closest target profile overlap?

2) Which aspects of a CRM does this solve now and in near future (Q4 2023)? eg: is it email sequences, existing customer tracking & BI, prospect enrichment, etc?

3) What sales/CRM stack are you using internally at Twenty // what are your peers using? How do you send bulk emails? How do you track signed contracts, revenue start dates, and so forth? Would love to get some info about not just dogfooding your own product but what you/peers use for your GTM.


It would sit in the second category. And probably even more on the right than the companies you mentioned on a spectrum going from "agnostic database UI" to "opinionated CRM tool with a rich set of standard objects/APIs coming out of the box" (which doesn't mean that you can't customize it).

1) Building a full-featured CRM is a long-journey. Our strategy is to start working with companies in our YC batch which have simple needs, and then deliver improvements fast enough so that these companies never outgrow us and have to switch.

2) We're focused on a simple B2B Sales use-case for now (log tasks, kanban, etc.). Next we will focus on data integration, connectors and extensibility. The goal is to become the best system of records for the company. That should allow connecting external tools to bring the best of breed app for each category (e.g. customer engagement, support tool, phone). Later on we will eventually invest in building our own Marketing/Support apps like Salesforce did but we're still very far from there.

3) Prior to this launch we only had a handful of people we were talking to so a simple Kanban in Twenty, no automation. And after that, we will remain focused on product development in the coming months so our team is probably not the best example in terms of Sales playbook. But once we want to scale the team and have built integrations, we will likely take the "best of breed" approach I was mentioning above, using Twenty as the central piece to connect Aircall, Braze, Docusign, etc.

(Great questions by the way, thanks)


As someone who recently built an open source crm (iceburg.ca - Laravel / Vue) I think your choice of license is very limiting. Limiting how the crm can be used will limit the number of users and handicap yourself. Focus on a great crm first and don't worry about others copying you and providing a saas solution better than yours. The more people using your crm is more important than preventing others from making money.

I debated whether to use your license because other crms like SuiteCRM are. I quickly discovered getting others interested enough to host their own saas platforms using my crm framework means more user interest in your crm. The hardest part is getting users to try your crm. That's what you want, not to try to capture imagined lost profit on saas hosting. Then with scale you can create a marketplace of addons and widgets that can capture the real profit center


I really like the metadata-driven approach of Iceburg, great work.

I don't have a strong opinion on licensing. We were setup as MIT until last week and ahead of this launch I thought that if for whatever reason we were moving to a more restrictive licence post-launch it could feel like we've been lying to the community. So we decided to adopt a more conservative approach to avoid making promises we couldn't hold later on. If people come to us with projects where this license is a blocker, we'd me happy to discuss and grant exceptions.


People don't really understand what Salesforce is and what they are good at. Yes its PAAS and so on.

But the core skill of the people at Salesforce is that they've had this thing online for 20+ years, most of their customers have extensive customisations, and three times a year Salesforce push new features to the platform while successfully minimising the amount of customer customisations they break.

And thats the key - how can you regularly expand and improve your PAAS without fucking up the extensive and very complicated custom things your customers have built on top of it. Its actually a very hard engineering challenge that no-one really talks about because its a long term challenge and not many people focus on long term engineering.


Yes good point, going with a multi-tenant infrastructure makes this very challenging as they can't ever leave anyone behind


What made you use Blocknote over EditorJS?

https://www.blocknotejs.org/ https://editorjs.io/


or TipTap/Prosemirror?


I thought building on TipTap would take too much time but I was wrong. I've looked into TipTap extensions and it seems that in less than a week you can build a very decent Notion-like editor. So we will be rebuilding everything with TipTap soon.

Initially I chose Blocknote over EditorJS because I wanted draggable blocks / something that feels more like Notion. But it wasn't a good call to make the decision based on that.


What issues did you face with Blocknote?


It isn't easily extensible (we wanted to be able to add images with drag-n-drop). From the moment you need to extend, it felt like it was faster to rebuild things directly with TipTap


Thanks


Really neat job guys! Some people see it as an inferior version of Salesforce, which goes beyond a CRM. But for a dev who loves open source & is looking for something that does only what a CRM does, it looks surprisingly good!

I have to give it a try :D


Thank you, we put a lot of effort into providing a good user experience and a good developer experience. Feel free to jump in on Github issues!


I love these open source alternatives to big tech and centralized solutions. So far I have seen:

- authentication and authorization with oauth: Ory (ory.sh)

- payments and billing (alternative to stripe): Lago (getlago.com)

and now

- CRM: Twenty

I'll look into this and see if I can contribute back. I hate SF


Thank you, happy to see you on the codebase!


this looks super cool and great ux (love the keyboard shortcuts, dark mode, notion-like experience). congrats on launching it!

do you have any plans to automate data entry? i currently use airtable and have tried folk, attio, etc. but my biggest frustration is it takes so much time and energy to manually add information about people and companies. would immediately pay $20/mo or more for a product that can automatically enrich any person/company data for me and sync with my calendar, email, twitter, linkedin, etc. to add people/companies.


License AGPL3.

Will not integrate with internal services.

https://github.com/twentyhq/twenty/blob/main/LICENSE


Do you have a specific use-case in mind that this license is blocking?


Connect my CRM to an internal system.

Let's for example say it's an AI power assistant for the sake of memeing Iron Man. I want to be able tell openai to generate a function calling method that takes a json schema and inserts the code into "Twenty.com" for data retrieval.

You can construct an alternative scenario with a bank's financial data retrieval.

It's too hard to think through the recursive cases through a network when it's considered "linking" in the GPL3 sense.


I'm not a licensing expert but I know AGPL has a concept of derivative work that is somewhat blurry for me. We could argue this isn't core to the CRM (if specific to your company) and therefore not derivative work but I agree it's subjective and therefore not ideal.

I'm not entirely convinced we made the right choice. Considering your feedback and we will see in a few months what people want to build and if we should revisit.


Can you talk a bit more regarding your go to market strategy ? How will you approach potential customers and what is your pitch going to be for them to get rid of SF in favour of your "untested" product - as how they would see it ?

I am more interested in the marketing strategy since I am working on a very similiar problem, but in a slightly tangential software which is monopolising the market. Any advice / insights on this would be appreciated.


Salesforce is the end-goal but we wouldn't be a serious alternative for enterprise customers today. Our strategy is to start working with companies in our YC batch which have relatively simple needs, and then deliver improvements fast enough so that these companies never outgrow us and have to switch.

It's a tedious process to get off a CRM, and particularly Salesforce, so it's much easier to target companies that are not using any tool at first and grow with them.


What was that factor that made YC accept you into their batch then ? What differentiator did you guys bring ?


Lots of comments about salesforce app exchange, but I will say, as someone (unfortunately) very familiar with Salesforce and also startups ... I think there is a huge opportunity here.

The Salesforce schema of opportunities is incredibly out dated for modern software companies — you only need to look at the explosion of "PLG CRMs" in the past few years — I think there is a massive opportunity for a CRM that integrates natively with Segment/Posthog to onboard event data.


We initially though pitching "Segment-native" or "Warehouse-native" as one of our key differentiating feature (we haven't build any of that yet). I agree nailing this would make a big difference


I'd focus less on specific integrations and more on having a modern CRM schema that suits bottoms up SaaS products. Exciting!


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)

* Cannot quickly add an opportunity without setting up the company (most other CRM products have a quick-add)

* 'Contact' appears to have a quick-add when adding an opportunity, but it doesn't work.

* All opportunities automatically default to Lost

* Dragging an opportunity into an 'empty' bucket does not always behave as expected (e.g. if you drag it to below the 'new' button)

* No way to add additional pipeline stages

* Users can remove all companies/deals/contacts from the system in two clicks with no limit and no way to reverse (:

* If you invite a user to your workspace, they are immediately admin and can kick you out of your own workspace.

* No way to archive an opportunity - the pipelines will just grow so will be totally unusable after a few months.

* Basic UI issues from a usability perspective - like two icons for people when you go into an opportunity, and not clear that one of them wants you to put an employee count in it, and then other field where you say employees doesn't actually seem to work. If I go to add people to the opportunity, it shows me people I have already deleted and does not show me someone I just recently created and assigned to the company...!

* No way to export data for analysis (e.g. to Excel). Conversely no way to import data (e.g. from Excel) so migration is impossible (companies will have 10's of thousands of contacts)

* Basic audit issues... If someone creates a note I can either delete it, or I can rewrite it and it looks like they said it (it doesn't say it was modified by another user and just lets me edit others notes!).

This is after like 10 minutes of testing so I assume there are lots of other issues too...

Broadly at the moment I don't think it passes the 'Being a better CRM than Trello' test, and definitely does not pass the 'better than a spreadsheet' test, but hopefully with time it will. At the moment though it feels very under-baked, but wish you luck in building this out into a product which is usable.


Thanks for the feedback! All of this is relevant and rather basic stuff I agree. Come back in 2-month and you might be surprised how much of it has been implemented :)

Launching early here was a way to get feedback from developers and thoughtful users like you, and we wanted to do it in the spirit of building together with a community. We didn't open signup on Twenty.com precisely for the reasons you mention.


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).


Mostly the commercial model.

We are fairly-lightweight users, and although only 2-4 people really use it (again infrequently) would like everyone in the org to have access to the sales pipeline and information.


I will say this whenever I can: Salesforce has a moat because of their ecosystem. Full stop.

You must create an amazing ecosystem to compete. But creating that ecosystem is incredibly difficult.

Honestly, my opinion for how you could maybe make it work in open-source is to recreate the Salesforce API. That's a HUGE effort though, as it has a big surface. (I wonder how much of that is intentional to make it so others can't copy it well.)


I mentioned it in another comment but Odoo is one of the best example of how open source could help us build that ecosystem. It has allowed them to work with a network of web agencies that customize and implement their solution

Product surface is huge indeed! That's why we're only starting with a small/focused piece.

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


AGPL is always scary. If I integrate your CRM code into my tech stack, technically I may need to make my tech open source, per AGPL. Thats dangerous.


We are unsure about the right license to use, so this is a great feedback. We had a MIT license one week ago that we know that we cannot hold on long term and we felt we were lying to the community by keeping an MIT license and changing it in one year.

By using AGPL, we feel it's the right level of restriction. It's the license used by Metabase for example (https://github.com/metabase/metabase) that many companies use internally. Obviously, we don't want to restrict people to self-host the CRM for their own needs.


With open source CRM I'd guess there are improvements or derivatives that you'd want to protect under AGPL, but then there are also "configurations" where it's adapted to a user's business and tech as mentioned. Having to release the source for these would be a non-starter for many. It would be nice if there was a way to make a clear distinction between how the two are licensed, though there is some gray area it may be hard to cover, ie when is it a new feature vs a configuration.


> Our tool only does a small part of what big CRM players offer, but we focused on providing a great user experience on the basics, instead of spreading ourselves thin across a vast range of features and delivering them half-heartedly.

I like this approach. So much software feels completely half-assed and frustrating to use. Quality can be a real differentiator (it just has to be empathized enough).


Agree! Linear is a good example of a company picking up steam with a design/quality-first approach when the market leader Jira suffers from feature bloat. Hope we can make a similar comparaison one day!


How hard was acquiring the domain twenty.com?


It cost us ~$100k from a broker. I've always loved nice domain names and I had some cash because I sold my previous company to Airbnb so I was happy to spend it!


Holy crap, is the name that great?


Haha, it's the usual market price for a nice one-word .com ; I don't see this as money thrown away like spending in ads for example, it's closer to a real estate investment in my opinion


The first thing that popped out to me when looking at your github repo is this need to be updated: https://github.com/twentyhq/twenty/blob/main/server/README.m...


Thanks! Yes :D We are publishing the repo as it is, and we know we have a ton of things to improve, including documentation! I had actually forgotten about this readme, will make sure to remove it https://github.com/twentyhq/twenty/issues/764


Best of luck. Would be happy to receive an email from your sales team once you have the equivalent of HubSpot marketing enterprise. As an engineer turned founder, I agree these products suck and the market is ready for disruption. Focusing on engineers and product quality is a good play.


Thanks a lot! It's a long-term play but we'll get there


This looks very promising. Excited to see how Twenty develops over the next years!

I think they key is to nail the data model and make sure replicating stuff from people's products and matching it with outside conversations (email, phone etc..) works smoothly


Thanks so much! Agreed 100%. Data sync has been in the top of our list since day one. We are still thinking of the best way to build it to make it work smoothly though.


This is fantastic. Unfortunately decision makers usually go with what they already know. No one was ever fired for choosing Salesforce. Hopefully over time more people get exposure to this and increase the adoption.


Thanks for the kind words! It's a very long journey ahead of us, that's for sure!


One thing I'd like to see improve is the contrast between UI components on Dark Mode. Currently using a MBP XDR display at 100% brightness and I can barely make out where the components start and stop.


Yes, we agree, this should be fixed before end of next week. Issue here: https://github.com/twentyhq/twenty/issues/668


Very cool product, seems like a good example of an SLC version =)

The open-source approach makes a lot of sense especially given the need around integration and customization (& awful developer experience of competition...)

Congrats on the launch!


Thanks Maxime! Had to Google SLC, for those who are reading it's "Simple, Lovable and Complete" — and exactly where we'd like to get soon yes :-)


Do you have plans to add an API or methods for analytics? It's common for me to ETL Salesforce data into to a data mart or warehouse to structure the entire data model for analysis and reporting.


If you self-host then that's easy since you can read directly from your own Postgres. We have a GraphQL API but I have to say I we didn't think much about how we could make it easier for people to export data if they don't self host (besides csv export in the app). Is an API enough or you'd expect more sophisticated connectors? You would like integrations with Fivetran, Airbytes, etc.?


We have been using the CRM as early users for the past weeks and are very happy. The Twenty team is super responsive and is shipping features quickly. All the best on the launch, Team Twenty!!


Oh thank you Lennard! Wishing the best for Langdock too!


How do you get data out of this? I see you mention GraphQL, but is there sample output? Are filters and searches etc. supported?

Also, can you write/mutate data via GraphQL too or is it read only?


Yes, we are providing a graphql API that you can find "documented" here: https://docs.twenty.com/graphql/

Right now, you need to provide a JWT token that you can get at login or refresh against a refresh_token (90days expiration). In the future, we plan to also support API keys which would ease a lot headless work.

Regarding filters and search, we have added filtering and search features on app.twenty.com. They are directly leveraging the graphql API.

GQL query example:

``` query ExampleQuery($where: CompanyWhereInput) { findManyCompany(where: $where) { id } } ```

GQL variables:

``` { "where": { "address": { "contains": "example" }, "accountOwner": { "is": { "id": { "equals": "user-id" } } } } } ```


We also plan to support CSV import and export


This is awesome. Thank you!


Looks interesting, i think i'll give it a try.

BTW your Github readme says: A CRM that ban self-hosted for free, on your own network and close to your data sources.

You might want to correct that one :)


Haha! Yes, fixing it, thank you!


Just in time for my app (Cancelly.ca) to use a CRM. I was going to code a CRM myself. I hope it stays open source. Like how OpenAI went from being Non-profit to for profit.


Yes it will! Not sure if you're going to self-host but we haven't published any click-to-deploy buttons yet so let us know if you'd like to self-host and have issues doing it


The app looks nice and great to see it as open source. I have one thing to nitpick, though. The app hijacks the back and prevents the user from being able to go back


Sorry this isn't intentional! I had just logged an issue here from a previous comment: https://github.com/twentyhq/twenty/issues/763


I thought CRM choices were a management decision, not a developer one. How do you plan on overcoming that, when management will just go with Salesforce or Freshworks?


Yes agree being open-source is not enough of an argument to win. It will help us build a community, foster innovation and thus making the product better. But at the end of the day, I agree the product needs to be the best for users, not just for developers.


The whatsapp app part does not open whatsapp just opens the App Store, deep links are tricky to get right,. Feels like a strange choice for a signup form /waitlist


It led to some fun conversations but most people just ignore the WhatsApp link. Definitely not something we're going to keep long-term. The initial goal was to be able to engage with a few users that were willing to, to do real customer interviews and not just have them fill an impersonal form


ooooh, this is nifty. I was just thinking we needed a good CRM! Are there any other good, self-hosted alternatives I hsould be aware of?


Not trying to hide our competition but honestly, we came to build this because I didn't find any.

The leader 15 years ago was SugarCRM but sadly they ended up getting bought by a PE fund and closing the source. There is a project called SuiteCRM[1] that continued with an open source fork but in my opinion they lack the "modern" touch that we were looking for.

Besides that, other options I've seen are Yeti [2] or Odoo [3]. Odoo is very successful but it's different because it's an ERP so CRM is only a small part of what they do. They tend do do a lot of things so can't do all of them very well.

[1] https://github.com/salesagility/SuiteCRM [2] https://github.com/YetiForceCompany/YetiForceCRM [3] https://github.com/odoo/odoo


Here's some open source insights regarding the repos mentioned so far.

https://devboard.gitsense.com/twentyhq/twenty

https://devboard.gitsense.com/salesagility/SuiteCRM

https://devboard.gitsense.com/YetiForceCompany/YetiForceCRM

https://devboard.gitsense.com/odoo/odoo

Some notes based on what I'm seeing are SuiteCRM and YetiForceCRM are not fully being developed in the open. The community around odoo is quite large and has close to 10,000 historical contributors. Twenty is new and picking up steam.

Full Disclosure: This is my tool.


Thanks for sharing! This is so good it could become our internal dashboard


Hey glad you find it useful. DevBoard just came out of stealth mode last week.


We use Espo (https://www.espocrm.com/) and while it's not the most "shiny object" ever it gets the job done relatively ok for our small team


And it's great for a team of thousands. Speaking from experience.


More opensource alternatives: https://www.opensourcealternative.to/?category=CRM


Reminds me of Zoho. They started with the basic CRM features and look where they are now. Keep at it!


Thank you!


This will be DOA. CRM is a essentially a solved problem.

However, since you are open source I think there is an opportunity to either sell the framework to ISVs (think a property management system provider who wants to provide CRM functionality to their platform overnight... like embedded analytics such as Looker) or have the community create industry specific CRMs.

Good luck.


Yes that's something we've considered. Veeva and nCino are two examples of billion-dollar companies built on top of Salesforce and verticalized in one industry, so there is a need for what you describe. If we want to go this path we would have to move to an MIT license. We will learn with the community and adapt!


> This will be DOA. CRM is a essentially a solved problem.

I was about to ask if it's possible to make money on CRM today, given the near infinite number of choices at all levels. But maybe it only works if you specialize, as you alluded to in your comment.


tbh - when i noticed, i can't delete my account, i instantly stopped going further.

As an european citizen: it might be interesting for you to cover aspects of GPDR, to attract european users (that are forced to use GPDR-conforming data handling).


Sorry about that, it's not an intentional dark pattern, just the result of a very short timeline to build this. I've just created an issue to prioritize this soon: https://github.com/twentyhq/twenty/issues/774

We are trying to be conscious about data privacy too (e.g. no tracker or third-party cookie on our website)


I get a ERR_SSL_PROTOCOL_ERROR on submit-form.com when trying to request access.


You can go to app.twenty.com ; twenty.com is our marketing website for a general audience so the form there is useless for now (we'll launch soon but our current focus on Github / developer community only)


Rooting for your success, legacy CRMs are without exception just unspeakably bad


Thank you!


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 turn means that I better have amazing IT capability in my leadership.

The corollary of that is: Without amazing IT leadership, my company is living on borrowed time, eventually to be crushed by dependencies on one or more 3rd parties like Oracle, SAP, Salesforce, IBM, Microsoft, Amazon and their ilk.

So the only way I’d accept strategic 3rd party software into my company, would be, if I have the ability to fully fork it and take it in-house at any time of my choosing, with at most a very manageable and finite remaining financial obligation after the fork.

If Twenty.com has a business model, that can accommodate that, it might be onto something special.


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.


Good to see that you're spending quality thought on differentiating by reducing the lock-in problem generally associated with the software/service space you're aiming to compete in.

My initial reaction is that the ideas you listed around data ownership and and extensibility hold considerable promise and allow a company to grow not only with you and your other customers, but also to create and grow competitive distinction.

And if you refrain from being sneaky about locking your customers in, it would probably limit the enthusiasm of most potential investors, but it would also be a chance to have much less antagonistic customer relationships and a much more likable public sentiment over the long haul.

And that gives me pause to wonder, if it might make sense to strengthen the messaging around the fact that you're not taking your customers hostage like most(all?) of the big incumbents. Is you current messaging possibly burying the lede?

You're most certainly picking an interesting time to start such an ambitious project. But then again, maybe -- exactly while so much is in upheaval -- now is a great time to do so! My warmest wishes not just for success, but even more for a fun and rewarding journey!

p.s. I noticed, what I assume to be a small typo section on your github page:

> For the developer community:

> A CRM that ban self-hosted for free, on your own network and close to your data sources

Was the intent to have something like this?

A CRM that can be self-hosted for free, on your own network and close to your data sources


Yes, as an engineer I am rooting for opensource and to build something that last beyond the company. I also think it will force us to install a good company culture centered around transparency and give back.

They are many example of successful businesses that are emerging while being fully/mostly opensource (Hasura is a good example).

It might be naive but we think it's the right time and we can get investors on board with that.

Thanks a lot for the warm wishes

And thanks for the typo! Fixed!


Looks exactly like what I have built with two notion tables :man shrugging:


Haha, if we were able to replicate the notion experience in 2 months that's a great compliment! The difference will come from the fact that we hold structured data. Notion doesn't know that a person is a person and a company is a company. That makes it impossible for them to build robust integrations CRM have. You can build rules to replicate some behavior, but once you have more business logic, it becomes too limited.

Next month we'll be shipping some features around email (log/send) which should help you see the different direction we're taking.


> Notion doesn't know that a person is a person and a company is a company. That makes it impossible for them to build robust integrations CRM have. You can build rules to replicate some behavior, but once you have more business logic, it becomes too limited.

I literally have a 'person' database and a 'company' database.

But yeah fo sho, it will get limiting if i make this much more complex lol


Am I hallucinating or was this posted a couple of days ago?


We posted yesterday (and never before)


It does seem very similar to my notion CRM setup...

Could this be on purpose?


What's your plan to make money? How long is your run way?


We'll focus on providing a cloud hosted version, because not everyone knows how to or want to self-host.

We don't really think in terms of runway yet as the company has just been setup. YC gave us 500k which we haven't spent yet.


It's amazing to see so many open source companies in YC


Yes there seems to be a trend! Way behind the number of LLM-related startups, but still quite a large group within the current batch


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.


Congrats on the launch Guys, seems awesome !


Thank you!


Today I learned that salesforce is like SAP


Interesting how you choose typescript?


We have mainly chosen to use JS on the frontend and on the backend to lower the learning curve for people that would want to contribute / extend it to their own needs. Then typescript (with its limitations!) it our best shot on top of JS, especially as we are using GraphQL


Do you have a hosted version yet?


Yes! https://app.twenty.com . It's still very early but we are happy to share it and to get feedbacks. We already have a few users that are using it on a daily basis and we are trying to get as much feedback as possible to prioritize our roadmap!


Awesome! Congrats on the launch!

Is the pricing for the hosted version?


The pricing is for the cloud version: you can use it for free if you stay under 100 contacts. Self-hosting is completely free!


Awesome! Good stuff Charles :)

What's the best way to contact you?


Congratulations and good luck :)


What's wrong with SugarCRM?


SugarCRM has been sold to a PE fund and close the source years ago. There is a project called SuiteCRM that took over the source code, and they did a great job considering it's a small organization, but it didn't evolve the way it would have if SugarCRM had remained open and under the same ownership


There's a lot to do in this space.

As a former CTO, almost every product I worked on had a request coming in at some point to create an internal CRM and I do believe in embedded CRMs as a software category.

There are even SaaS categories that could use some CRM-like ability (e.g. link building tools, procurement tools, debt collection, ...)

Open-source would be a good fit for that model cause you could take it in-house if you need a lot of customizations.

Some painful CRM issues I encountered:

- Pregnant funnels

when sales sets up the funnel stages in a way that leads can go back through the stages (e.g. "next meeting scheduled", "follow-up" or "offer sent") so a deal passes through the same funnel steps several times.

Not sure there is much you can do about that except for dynamically creating more stages in the funnel

- Last-stage-changed-at

Another issue is that CRMs don't keep event logs of what actually happened and just keep the last stage and when you changed that stage; this makes it impossible to analyze stage-durations and correct for cyclical stage switching (see pregnant funnel problem)

- Call quality

You would think that in 2023 voice-over-IP would be super reliable and works every time but I can guarantee you that in a 30 people sales team you will have many! complaints about call quality if you only rely on VOIP.

Always have the ability to call the salespersons' real phone number (over the traditional telco network) and then call the client once the sales person is connected. (a sort of conference call).

This kills all call quality issues as there is a fallback to dedicated phone networks.

- Call activity recording

Call activity recording is actually very important because apart from pipeline reviews, tracking sales call activity is one of the only leading predictors of sales success (it also catches lazy sales ppl).

Related to the above, some CRM's are able to record the calls with VoiP but fail to do so when real phone networks are involved.

- Cell phone masking

When using CRM calls, in hubspot and zendesk you can spoof the phone number; this is typically set to the salespersons' cell phone so the client can call back but when the client calls back the call goes unrecorded.

- Lack of IVR menus

IVR is a part of every PBX setup but they almost never play nice with CRMs; only Aircall integrates IVR menus but it relies only on VoiP and was a huge nightmare (see call quality issues).

- Treating leads and deals as separate records

It's surprisingly hard to build funnels that go from "this person filled in this field and has these UTMs parameters" to "which UTM parameter made actual money because almost all CRMs have a dual LEAD/DEAL record.

They typically destroy the lead and it becomes a contact which often has no stages anymore.

Nobody in Sales and marketing thinks about it that way though, it's more "here's a lead and then the lead progressively discloses more information"

I always think the best datamodel for a CRM is an event-sourced log with a giant json blob representing the latest stage that can be rebuilt from the event-source log.

- Outbound email chains

Most CRMs use their own email address and the main company domain to chase prospects (and setup automated email chains), which as you can expect sometimes get spam-listed; the ability to email through a separate domain and to capture replies properly is needed.

My current solution is to just ban the use of automated email chains but I've seen other companies use mailgun to create a proxied salesperson' inbox.

- Closing the loop with marketing

Google analytics and facebook has tags you can use to indicate the actual deal value of the generated lead. You can say this click led to 1k in revenue; except it's a huge pain in the ass to do this because of the lead/deal breakup and often the original contact details change as the sales person gains more trust.

Another option would be to export events to analytics tools like Amplitude so you can get a complete marketing-product-sales funnel


Forgot one

- Meeting activity tracking

Meeting scheduling is kind of covered now but meeting activity tracking in CRM's hasn't caught up.

Also these types of calls and call activity is unrecorded now

This issue got worse since video calling is often the default


You should have launched with integration. This is a waste of a launch.


There is a ton of great feedback from users in this thread that will help us build a better product, that's enough to justify this launch in my opinion :)

Noted for integrations as a top-priority!


JavaScript on the back end? HARD pass.


Haha, I was waiting for a comment on programming language choice.

It was my first time with JS on the backend and I really enjoy the dev experience with Nest. Sadly, we can't please everyone


Customer relationship management (CRM)


You guessed it!




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: