Launch HN: Twenty.com (YC S23) – Open-source CRM
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?
316 comments
[ 4.5 ms ] story [ 68.6 ms ] threadThe signup from the main site asked me to message on WhatsApp, which I don't use, so I backed out from signing up.
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.
Great feedback that we should prioritize it as early as possible, thanks!
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 ?
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
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.
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.
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.
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.
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...).
I'm glad to see I'm not the only one with a long memory.
Or maybe that's better described as PTSD.
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.
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.
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
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.
https://developers.hubspot.com/docs/cms/data/serverless-func...
- 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.
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.
> 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.
And Microsoft through the Productivity apps? (Word, Excel...)
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”.
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
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…
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!
I have never used nor worked at an organization that is built on top of Salesforce.
Just a regular web dev.
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.
We are a very M$ bias company, hence, no slack.
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.
Can you please name these softwares?
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.
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!
[1] https://attio.com [2] https://www.folk.app
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.
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!
* 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.
I'm the cofounder of Budibase.
A lot of CRMs seem to evolve into general purpose platforms - Salesforce and MS Dynamics being the ones I am familiar with.
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!
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.
We definitely need to work on integrations soon!
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.
https://www.blocknotejs.org/ https://editorjs.io/
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.
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.
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?
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.
> Interesting, I will look into that, thank you!
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.
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.
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
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.
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 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.
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?
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.
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....
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.
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.
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).
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.
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!
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.
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 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!
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.