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?
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!
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
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.
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.
I wouldn't use that as a source of inspiration, at least not on the "connectivity" end.
Emulating AirTable usability with a CRM focus would be a category killer if successful.
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?
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....
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 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.
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
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.
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
Deleted Comment
If you ever plan having different things, better keep them in mind at the beginning - bolting them in afterwards may be cumbersome.
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.
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!
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!
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
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.
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.
Dead Comment
The signup from the main site asked me to message on WhatsApp, which I don't use, so I backed out from signing up.
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.
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.