My glib take to every CRM like this: If you don't ship with a programming layer you're DOA. Salesforce thrives off of Apex and friends. You _need_ to let people program your CRMs if you want to go after SFDC. Or, more specifically, you need to _host_ people's programs so they don't have operational questions.
Salesforce gets the ubiquity the same way that Wordpress does: randos can copy some code fragments off of a website and stick it into a file/textbox, and get new functionality.
So... Twenty, hire one person whose job it is to layer AWS Lambda over your system :)
Hey, just seeing this thread now. Agreed!
We've started a year ago and have done probably just 10% of what is needed to really get to Salesforce.
We need (1) a flexible data model, (2) a flexible layout, (3) code execution.
We've done (1) but have yet to do (2) and (3) this year.
Next step of the plan is to let people build and share apps that leverage those 3 blocks, that's where open source will really shine!
Can you elaborate on what "a flexible layout" means in this context? Is this data layout, i.e. serialization format(s)? UI layouts for displaying values in the data model? Something else?
(We too are in the "let people execute their code on our servers" space; providing a flexible data model seemed to have been key)
Most businesses are not big enterprises that need a programming layer. You can focus on that later on when you actually found some traction and move up-market. I don't think starting with enterprise features is "DOA", it's just smart prioritization.
You don't want to go through enterprise sales cycles when you are just starting your company.
> Your assumption is that having a programming layer in a CRM is only for big businesses. But that's not true at all.
I read it to mean that "A programming layer in a CRM is only for those businesses that can afford a programmer", which, TBH, are only big businesses.
Which is why small companies may not be able to afford making Salesforce fir their needs exactly - the cost to hire consultants to come in and panel-beat the system to fit is higher than the cost of continuing with spreadsheets.
> "A programming layer in a CRM is only for those businesses that can afford a programmer", which, TBH, are only big businesses.
That just is not the case. My first job was working as a solo Salesforce admin/dev for a company of < 150 employees and we made extensive and valuable use of the Apex layer.
Your assumptions are inaccurate, and that is leading you to inaccurate conclusions.
Right - presumably the target market are people wanting something other than Excel or Google Sheets, which they likely already use programmatically not just for data entry. Is that right?
I've worked with big and small businesses that use salesforce and they all have some kind of programming layer. Small businesses tend to buy plugins or pay some contracting firm to write customizations.
> You don't want to go through enterprise sales cycles when you are just starting your company.
There's definitely a gradient here. If you are good at juggling sales cycles, you can close "small enterprise" deals. And if you have a good programming layer, instead of going through a full dev process for each thing, you get "integrators" working on things.
The advantage here: once the design is done, you're writing a handful of 10-line scripts. You can have a design meeting, have a person sit down for an hour, and ship out a thing that closes a deal. And the design can be done for _just_ the company's needs instead of a full flow. You can charge an "integration fee" to the customer in this case as well.
A programming layer lets you remove a huge level of tension that comes with B2B sales: juggling specific client needs with your product needs.
I run a CRM platform for many years. And while this is true, that if you want to go after a subsection of SalesForce type customers, you do need a programming layer. However, that is only a specific section of the market. There are vast amount of users out there that do not need that and will never will. They need a CRM. Not a Platform-that-is-also-a-CRM.
We offer 100% API access, and customisation from the data layer to the UI (very very flexible), but I'd be reluctant to invest time in adding an actual programming layer like APEX on top of it. I don't think I'd want to even go to that level of "enterprise" customers and everything else that comes with it.
Edit: just because I've seen people plug their products here as well, I'll add mine: https://cogmento.com
I think it is easier said that done. The GTM completely changes of a product like this. Now you have to build API, DSL and eco-system to support it. I absolutely agree that your take. But building an eco-system is hard.
You don't need a DSL if you, for example, "just" use Javascript. You need an API anyways. You do need to do some operational fudging around of course.
I'm going to also counter with something super important: you build out stuff like this, and suddenly you can handle your own feature requests faster. User wants X to happen after Y? Write a tiny event script that they install into their env. They need some bespoke field? You have custom models, and now your events reply to that.
In the fractal of requirement differences that is sales pipelines, not doing this just feels like causing yourself a bunch of dev pain.
From a technical perspective, how would one structure a program like this? Where the main developers also use the same 'engine' to develop the product itself, while also exposing the same engine to the third parties?
The first such case I have seen was Maya (the 3d software) when it first came out use a custom scripting language called MEL(Maya Embedded Language) to develop the entire user interface and corresponding actual entity manipulations. Third party plugin developers also use the same MEL.
I thought wow, and that is still impressive today.
I work with a CRM that allows users to add additional functionality by uploading definitions in XML "spec" files.
The XML specs are a combo of metadata and code and define all functionality in the system including SQL tables, forms for adding/editing data, query nodes for the internal query system, arbitrary business processes etc. They can include SQL stored procedures to run or call out to bundled C# code, and they can be accompanied by HTML templates that generate UI elements where appropriate (e.g. user facing forms).
There are a lot of moving parts and the documentation is a bit patchy but it's a really ingenious system for adding modular functionality, particularly in a CRM setting. Pretty much all of the "official" functionality is built using this spec system.
> You don't need a DSL if you, for example, "just" use Javascript.
I'm in agreement, but I think you still need to build tooling around it.[1] At the very minimum:
1. The code editor needs to be part of the system - pointing the customer at VS Code is a dealbreaker.
2. Debugger needs to be provided: you can't ask the customer to hit F12 and learn how to use the browser's devtools.
3. Documentation is still needed: At least one folder of samples/examples, and at least a single exhaustive reference of all the functions provided by system.
Finally, I wouldn't go with Javascript: Non-developers are less-likely to understand something as complicated as Javascript.
You're using a language that has subtle and hard to find bugs if variables are declared in one of three ways, when a different way is more appropriate. Same with the two different ways to define functions. Same with the difference between all the forms of a for loop. Same with the distinction between a prototyped object and a class. Same for the usage of instance variables vs class variables.
Add typescript support to the mix and you may as well not even bother looking for customers.
[1] I just created a system that uses a vanilla webcomponent for client-side includes of HTML snippets, using only HTML. It's not possible to now set breakpoints in any `script` element that is included using this webcomponent, e.g. `<my-include remote-src=./common-stuff.html>` where `common-stuff.html` has script tags.
This is a developer's answer to a business problem. Scriptability added to a non-developer's tool is usually just enough rope to hang them on IME, and often ends up in a whole arsenal of footguns.
IME, this is how an enterprise-contender product should generally be built when it wants to touch many domains across the business. Starting with a reasonably rigorous access control model enables deeper business integration--and this is a product that, to be successful, can't live without that.
Man, if only SaaS would do just this instead of reinventing the wheel with their brain-dead scripting languages and limited APIs where they remove useful information and links between data.
Not sure. In my experience a lot of companies dont do any custom coding for their CRM and if they do it is usual basic stuff that can be done with a zapier integration (add lead to CRM when form is filled). An API is probably good but dont think every CRM customer needs APEX level API.
Yes, we(Windmill)'d be a kick-ass combo. We're users of twenty ourselves. As both open-source projects, a third option that I'm often recommending is having such great integration in both products such that their users can independently chose to use and install Windmill (self-host or cloud) and have it power all of the orchestration and arbitrary-code needs of the third service without the need for a formal whitelabel.
If they could inject their data model into the Windmill IDE so autocomplete worked, that would be...very good.
Edit: also - just to say this now, because I always say it, but having a way to embed this stuff into normal software development flows, with Git / code review / CI / test automation / Docker (maybe) / different environments would be very helpful.
I don't know if you do or not, but my main problem with anything like this is the makers are really keen to show me how easy it is to put stuff into production with 3 clicks, and that's the last thing I want. If I went back into business systems, I'd want a great tool that lets me support a large business with a tiny software team, so the business doesn't have to try and replace software people with business analysts because you need too big a software team to run it cost-effectively.
A few months ago I was looking for some software that was CRM-like. We are a bit non-traditional, and don't fit neatly into the typical CRM use cases.
Twenty was almost what we needed. It was extremely easy to set up, the customization is very promising, and the REST API worked ok.
The main issue is that it was pretty alpha-version, and I ran into quite a few small issues that just just made it not quite work for us. Either way, I'm keeping an eye on it, and will re-evaluate again at some point. Hopefully it keeps its customizability.
My startup [0] works with a lot of companies that are non-traditional, as you put it, and gives you the tools to design a CRM (and other business tools) that actually suit your business, if you want to check it out
We are academic group who is looking to increase collaboration both in industry and academia. While we have "products" (which we don't sell), we also have other initiatives like an education program. We also may want to set up a consortium with industry, which may include them giving us money, but not in a "buy a product or service" sense (but still needs to be thoroughly tracked).
So I'd really like a platform that holistically tracks people and our engagement with them. Some of this is done by traditional CRM, but the focus on selling products & services is too narrow.
Some desired features:
* Tracking our contacts, so we don't forget to follow through on something (CRM generally does this)
* Tracking people through time. If/Where they did their PhD, postdoc, are they in industry now. CRM I've looked at tend to be very fixed-point in time.
* What their research interests are and have been. Are they in an area we are looking to expand into? What conferences do they typically go to?
* How they have engaged with us before. Was it through an educational workshop? Did we mentor them in a mentorship program? Just someone we met sometime and seemed interested? People can be part of multiple groups.
* If they are using our projects, how are they using them? We are looking for good stories to give to our own funding agencies (and for general marketing).
* If they are interested in giving us money, what is the status of those talks?
If there's a better term for software that does this kind of thing, I'm very open to ideas. This isn't a strength in academia, as is pretty obvious, and I'm very new at this :)
You seem in a unique position with respect to needs and opportunity. So
many organisations go looking for a tool mainly to quench a vague
desire to systematise. The temptation is to think, "we can't be so
different, surely there's a solution out there that already solves
this problem". Reuse, not reinventing wheels, all fine and
good... but in fact the "problem" is ill-formed and before you know it
you end up fitting what you do, and your horizons, to a tool not of
your making, adapting what you do to someone else's paradigm.
So why not build it? Sounds like you have the academic and research
resources. It's just entities, relations and timelines. There's a
thousand ideas out there in games, logistics and asset tracking that
are so nearly what you want and can be adapted. Many now well known
tools only evolved as a side effect of another niche business need, to
scratch a singular itch.
I've been using https://clay.earth for this - it does #s 1-2 by default, and the rest can be done with notes on a particular contact. More people focused than lead focused so might work for what you need
What features were you missing? Currently Im part of a team making a CRM based on more niche kind of customer and were trying to retrieve more information about what other CRMs lack
I wish them the best, but I think they would have been best not drawing the comparison to Salesforce. IME people buy Salesforce not for the CRM but for the force.com platform. The ability to seamlessly build business logic over the entire flow of a business is Salesforce's bread and butter. CRM is a small part that definitely gets heavy use, but it's only a small part of the larger picture.
If they had a way to quickly spin of LOB apps like Salesforce does, and had implemented a CRM on top of that... I'd say they would be much more apt drawing the comparison. Particularly if that doesn't require code to do. I know a LOT of companies that would pay dearly for such a hosted platform, GPL or not.
It's probably wise as a startup to not go for Salesforce parity while building out the core roadmap. You can build a decent business catching new companies and paying attention to their needs unencumbered by the expectations of "switchers".
I agree with your points about what people want / expect from Salesforce. Would kind of be cool to see a CRM have AppExchange + SF data model interoperability.
I'm not a fan of Elon-style "pitch FSD or promise things that you don't have" either. But we had to find the right balance between expressing our vision and expressing where we are which you can see through screenshots/product demos.
The vision is definitely to have something extensible and more powerful than force.com ; we aren't there yet because we need to build strong foundations before that. We already try to separate our business apps from the core engine in the code base to learn what will be the right api and get ready for that next step when it's time.
If that's the case I'd encourage you to take away a few lessons from Salesforce:
1. IT is not your customer. The business is, and they don't know how to write code. Based on what I saw thus far; this is your biggest weakness. The only way to extend the platform at the moment is to self-host and write code.
2. Avoid baking crazy logic into the system now that you'll be unable to fix later *cough* SF 'standard' objects *cough* that will behave in very weird ways.
2(a). Person Accounts look like a good idea. But, they aren't; and never will be. They just create a lot of complications later when someone gets married or starts a business.
If they had a way to quickly spin of LOB apps like Salesforce does, and had implemented a CRM on top of that... I'd say they would be much more apt drawing the comparison. Particularly if that doesn't require code to do. I know a LOT of companies that would pay dearly for such a hosted platform, GPL or not.
I'm curious. What would you use for that today? MS Dynamics? Airtable? Budibase? Appsmith?
After trying out a bunch of tools, I found Appsmith worked best for me but for some cases I had to move on to Windmill (which is not exactly low-code but can be)
I absolutely love Windmill. The ability to stitch scripts together into workflows is great.
100%. You also buy Salesforce because your salespeople demand you too. It's something users are familiar with and excel in. Dislodging an incumbent is a lot more than just the technical product itself.
Twenty would be better served not marketing itself as an alternative as it isn't really an alternative. Instead, focus on their strengths and hone it on a niche audience. Useful guide by April Dunford, who's a guru at positioning (and coincidentally had repositioned a CRM tool previously!): https://www.aprildunford.com/post/a-quickstart-guide-to-posi....
What's ironic about ecosystems is that (as an integration developer), getting devs to build on your platform is so easy if companies would just help them connect to users to better understand their needs, and then give them the necessary endpoints.
I, and many others, would jump to build on basically any tool that facilitated those relationships.
Yeah IMO its a red flag to compare yourself to Salesforce unless you:
* Offer a managed database system that can support common ETL workloads, custom fields, event hooks like post-save, etc
* A embeded-DSL for scripting custom actions, no an API does not replace this functionality
* Consultants/Support-engineering/and other escape valves when a really important business process needs to get fixed or built NOW
* A lot more
And frankly many startups don't have the muscle for this. Its not easy to do database work and its not easy to create functional (not necessarily good, just functional) DSLs and programming languages. These are harder computer science problems that take real talent to solve well. There are valid reasons Salesforce has the market cap it does.
Nice! It's great to have more open source platforms in the CRM space.
This feels a lot like Directus [0] except that the latter is a more general data platform you build upon. They have a 100 Apps in 100 hours playlist where they build sample apps on top on Directus, even a simple CRM [1].
I wonder whether it's possible to write custom code on the platform (to automate processes)? In Salesforce, it's called Apex, a Java like language which allows to write trigger, and is the server-side language for frontend interfaces (written in LWC, Visualforce, etc.). Speaking of, is it possible to extend also the Twenty interface with custom written code?
Salesforce has barely evolved in the last 15 years. Apex (as mentioned previously) has not changed the slightest. In 2010, there was Visualforce, it's been pretty good despite a bit slow. LWC just got slower in general while trying to look fancy with some CSS. And the rest has been the lack of competition making the success of Salesforce, or, in the defense of Salesforce, Salesforce has been way ahead of the competition 15 years ago. And maybe the competition is finally catching up?..
I am looking for a personal contact manager that has integration with a personal calendar. I have talked about this with my wife who has moderate ADHD: it is harder for her to manage relationships, because she generally lacks a perception of time. Getting gentle reminders to follow up with a friend or acquaintance would be very helpful. But none of these are business relationships, so maybe looking for CRM software is barking up the wrong tree, even if open source and extensible. Is there anyone in a similar boat that has found a good solution?
Consider https://legendapp.com/ or https://noteplan.co/ for nice note integration with your calendar. You could easily create a list of contacts in these systems and trigger various events (singular and recurring).
This one grants a right for the service to use your content however they wish. An absolute showstopper for me, honestly.
From their Privacy Policy:
"You retain any and all of your rights to any Content you submit, post or display on or through Service and you are responsible for protecting those rights. We take no responsibility and assume no liability for Content you or any third party posts on or through Service. However, by posting Content using Service you grant us the right and license to use, modify, publicly perform, publicly display, reproduce, and distribute such Content on and through Service. You agree that this license includes the right for us to make your Content available to other users of Service, who may also use your Content subject to these Terms."
I built IceburgCRM (available in Django or Laravel). You can create a specialized crm with only a few words. For example: "create a stamp collecting crm". Modules, Fields, Relationships, Subpanels, default data and even a image for your homepage is created.
Data can be imported/exported into 6 different formats. Supports unlimited many to many relationships, 26 different themes, etc.
If you're modeling one workflow for one team at one organization, it's always been trivial. Same as making an issue tracker.
The complexity arrives when you need to support complex and branching workflows, teams that model things subtly differently, organizations that model things radically differently, strongly opinionated stakeholders at key teams/clients, endless demands to integrate with external systems, etc
Right - for most companies, they are one org. The complexity of "product CRMs" as opposed to "roll your own CRM" seems to come from trying to satisfy mulitple orgs. A CRM that can satisfy two orgs seems about 10x more complex than a CRM that can satisfy one.
LLMs might tip the calculation of buy v build enough that "roll your own" becomes the standard for most business apps.
Major mistake, unless your company is building and selling CRM software. Focus engineering resources on core competencies and buy everything else off the shelf.
Sure, but I mean something that can actually fit in with the rest of the systems running a decent sized org. On the surface a CRM seems trivial to make, a pretty simple db schema with a pretty simple UI. But, I haven't done it.
Excel and Access are (/were) relatively interoperable with other things, which is why they were historically popular for these tasks.
But the more you want to integrate with, the more complicated it becomes. The big advantage to off the shelf CRMs is that they often have many integration options readily available.
What i wonder about with roll your own, is the more you roll your own, the more you can build a single system around a single db with a coherent schema for the entire/most of the business.
DIY an ERP? It's possible... but it would take a very special kind of organization to pull that off successfully. It would need to be an organization with a particularly high ratio of engineering talent to business complexity.
It typically takes over a year and more than 1 million dollars just to implement a commercial ERP system for a large organization. Starting from scratch would be quite the endeavor.
ERP + everything else that would would call "business application software". Like, you wouldn't recreate twilio, or stripe, or build you own database or data warehouse or anything.
Seems like it could be done if it were done from the start.
Seems like a lot of the issues are understanding a good db schema. Screw that up and you are in all kinds of trouble.
Yeah, I think doing it from the start is the best chance for it to work. Otherwise it's a significant manpower issue to implement all of the accumulated business processes within a reasonable period of time.
I've built a couple of systems that manage the majority of custom business processes for some small/medium organizations over my career -- but when it comes to processes that are fairly standard, e.g. accounting, it's a lot less pain in the short term just to just buy something off the shelf. Although for truly unique processes, it is nice when custom software does exactly what is needed. But most businesses aren't very unique.
I think the reason most organizations don't do this is that most businesses aren't business software engineering businesses, and the little precious labor that a small growing business is able to hire is better allocated to a profit center.
> Seems like a lot of the issues are understanding a good db schema. Screw that up and you are in all kinds of trouble.
This is much easier said than done. On more than a couple of occasions, I've seen technically well designed databases steamrolled by organic growth in business. Processes change, legal requirements change, customers change, the business changes, etc. Then you're left with a well-designed database that solves the wrong problems.
It's all possible -- businesses build custom software all the time. But there's a reason off-the-shelf software sells.
Excellent, I wish we saw this a few months ago, we just bought Freshsales.
In terms of Wishlist we’d love to see: quotes/invoicing (support for product SKUs etc), document generation on deals (NDAs, proposals etc)
I think that’s the extent of the gap between Freshsales and this that we actually use.
In terms of integrations it’s great that Twenty supports webhooks. Any idea a good starting point for integrating something like Xero? Is there a repo of integrations other people have mangled with that we can tweak or reference?
Disclaimer didn’t actually take it for a spin yet.
Just again for emphasis.. so happy to see a really good open source option for CRM that isn’t designed like it’s from 2000s. Flamin’ hubspot and salesforce wanted circa 2% of our ARR per year and fresh sales was a compromise.
Hmm it's kinda hard competing with the big dinosaurs because enterprises are so incredibly locked into them.
And salesforce at least innovates with modern interfaces. It's not legacy trash like Siebel.
Salesforce is pretty good all things considered. When we had siebel, we'd lock all the new callcenter agents into a sweaty training room for a week, where a boring old guy would endlessly drone on which button to push in which scenario. Unfortunately this was actually needed. It was that bad a product, and it was completely unusable due to all the horizontal scrolling everywhere. It's just as bad as SAP (these guys are also soooo bad at UX).
Salesforce by comparison works a lot like facebook. People grok that naturally.
Note that if you self-host this, that you are bound by those code publication requirements of the AGPL 3.0 license that apply to your specific circumstance.
Does the $9/user/month plan exempt paying self-hosted users from those requirements?
> Note that if you self-host this, that you are bound by those code publication requirements of the AGPL 3.0 license that apply to your specific circumstance.
Dear everyone, please remember, the restrictions are on AGPL is about making changes and not upstreaming the changes. You can absolutely run it as a service, or as a networked part of your application.
For example, if you wanted to remove their branding or some message in an email or a link on a webpage from the source code, you could absolutely do that -- as long as you release the forked code under a similar license in the public sphere.
Businesses still won't touch AGPL (for now) and that's what they're going for to encourage enterprise signups (I find calling it "GPL-licensed" is a little misleading on the front page, but I get why they did it) -- but I think at some point that will probably end. I'm glad it's still going though, more chances for people to make money doing F/OSS (AGPL is free software).
I don't get what you're saying. Why would a self-hoster care about the code publication requirements of the AGPL? It's an OSS project, the end user doesn't care if the code has to be redistributed, they're not profiting from it remaining closed.
Incorrect. For example, the relevant paragraph from the Google doc linked elsethread:
> any product or service that depends on AGPL-licensed code, or includes anything copied or derived from AGPL-licensed code, may be subject to the virality of the AGPL license. This viral effect requires that the complete corresponding source code of the product or service be released to the world under the AGPL license. This is triggered if the product or service can be accessed over a remote network interface, so it does not even require that the product or service is actually distributed.
What the OP is talking about is an aggregate, ie. two distinct pieces of software talking to each other over an interface, which is explicitly "non-viral", cf. AGPL v3 § 5.
That being said, the AGPL v3 is on the more arduous side of things, so it's easier to avoid them completely in a business context.
Sure, that seems like a reasonable interpretation to me.
However, I don’t have any specific recommendation against AGPL v3. Accounting is just one specific field where licensing virality could have particularly complex implications.
I don't think that's fair, Google is a monopoly with anticompetitive practices. Why is it a shocker that they would forbid AGPL? They want to have their fiefdoms while charging exorbitant rents. They can't compete fairly.
Also there are plenty of profitable software with AGPL licenses, some even get acquired by public companies [1].
At larger organizations, a significant amount of the custom code in CRM systems are proprietary business rules... e.g. pricing calculations, business rules regarding the fine details of internal and personnel operations, etc. It's not uncommon for them to contain information that is covered under NDA, which would be a non-starter for redistribution.
Would love a product like this that offered pricing on a concurrent user basis or similar.
We have 15 people on our team but 90% of people might only log in once a month to have a look at the pipeline - don’t want to either have a shared account or to pay $150/month so we stick to a spreadsheet.
Lots of people on this thread saying you need a full programming language integrated - I’m not so sure HN is fully representative of real end users.
I find this take interesting. Some software venders, like Autodesk, offer a token based system to charge for actual usage instead of a flat subscription fee.
On a team of 15 people, $150/month is enough to maintain an internal tool? What is your average loaded cost per employee?
Currently the biggest blocker, even for simple use cases that don't have to add automation (there is no clear way to add customized automation), is the lack of permissions. Everyone has the same access to all the data!
no comment on this product specifically, but large takeaway from hitting a point where my side thing had actual users + communication -- CRM is critical
if you asked me 24 months ago I'd tell you CRM was a BS category, now I think of it as a backend component on par with the DB
CRM selection heavily depends on stage of the company and GTM motion complexity. I would never recommend to anyone to ever start with SFDC, but I can't not recommend ending there.
csv file with emails + python thing to send them using postmark
it took an hour every time I had to do anything, and I ended up with a collection of python scripts that solved random problems that were already solved somewhere else, which grew and grew
I tried a few programmable shared inbox tools and they were all clunky and meh. tried lighter things like supabase + some golang list manager, also meh.
postmark has a CRM they acquired, iirc it was too expensive
zoho seems reasonable on price, but did not try it
but to be clear, even if I paid up for something dumb like hubspot, my life would have been simpler and better
Is it planned to add support to CalDav and other Emailproviders? We are not using services from the Google universe but are thinking to switch to twenty
Among the modern CRM players like Attio, Folk, Clay, etc. how does this compare?
Anybody tried all of them? It’s impossible to get impartial info on software these days due to all the scummy affiliate marketing/paid-influencer/“Top 10 Best” crap that has taken over Saas.
Have spent extended periods in the last 12 months with Pipedrive, Attio, Salesforce, and Hubspot, if this helps:
Pipedrive - simultaneously lightweight and no-frills whilst impossibly slow and antiquated. The simple act of navigating through records and performing actions is laborious. The price is extraordinarily high relative to the UX and functionality (same ballpark as Attio, the clear leader IMO). Same category as Gem (ATS) to me – I'm sure lots of people are working on it, but with a slightly resigned air as they see Ashby building a way more performant and capable product.
Salesforce – not as slow as I recalled it being in ~2015, but still pretty "heavy" feeling. Commercial terms are as unpleasant as ever,[^1] and the professional services + 'does anything you need' angle is IMO designed to bamboozle non-technical stakeholders into outsourcing significant portions of sales and operations engineering to Salesforce Ecosystem® Trusted Partners® or whatever they're called. Unlike Attio (which embraces the fact that yes, this is just a fucking database with useful workflows on top), Salesforce seems to do what it can to prevent you from feeling like you're interacting with a database (right up to and including making it less convenient to use than, say, psql).
Hubspot – It's not a huge N, but of the half-a-dozen occasions I've spent time with companies using HubSpot, at least half the time people hated it because it had been misconfigured or inexpertly set up. The CRM side is, I think, relatively benign, but attribution modeling and campaign tracking is a poor UX in my opinion, and I found myself exporting giant .CSVs to analyze with Excel and Python. (Saving grace: Dan Lyons didn't enjoy working there, which suggests that they might be doing something right culturally[^2])
Attio – It isn't perfect, but it's the first CRM product I've used to be just good software, without the "for CRM" qualifier. Model is that it ingests all email traffic and calendar appointments from registered seats, offers rich support for creating data models and relationships (e.g. we have objects representing Deals, Contracts, and Invoices and the associated attributes in Attio – making it a general purpose "Customer OS" for us), has the right mix of powerful but not overwhelming tools for reporting, batch emailing, etc. Has its quirks (floats are limited to four decimal places, you have to create new lists before you select the objects you want to store in it, etc.) but it's outstanding software, trivial to integrate without writing too much code, and by leaning into the idea that yes, this is a database, so yes, feel free to define models and relationships and attributes, it is rapidly integrated into the workflows of technical users.
HTH!
[^1]: In 2015 or so, I had a "friend" who found that his colleague forgot to set a reminder for the renewal/break period in a 24 month Salesforce contract, belatedly tried to activate it, and was told that the contract had automatically extended for a further 24 months. Said "friend" created a fake General Counsel on LinkedIn with a real company email address, created a reasonably convincing email thread between themselves and the fake GC (FW: Salesforce Renewal "Is this legal?" RE: FW: Salesforce Renewal [Hastily googled legal perspectives ending in an admonishment that GC was bored and would love to sink their teeth into this dispute) which they "accidentally" forwarded back to Salesforce (even going so far as to do one of those silly honor system Outlook email recalls). The renewal was rescinded pretty quickly!
To beat salesforce you need to win over the admin/rev-ops or trailblazer as SFDC celebrates them. They throw monthly events in their skyscraper in every major city globally and an annual retreat/festival called Dreamforce to keep them loyal. It's not a better tech problem, it's a network effect. Good luck ripping them from the church of benioff.
You are also competing against a beast that locks in multi year contracts and is embedded so much within a company's ecosystem that it is almost impossible to replace them. Sorta like JIRA/Confluence.
Purchase decisions for products like these are almost always at the C-level. Very rarely do they actually understand the details of each product's feature set, especially the deepest 20%. You're competing on your ability to convince that decision maker to commit to a new product, as opposed to "nobody ever get fired for buying IBM (Salesforce in this case)" syndrome.
It's the same thing, by proxy. They may not know the details of that 20%, but they can be comfortable knowing it is capable of accomplishing it because of its use at other orgs.
Salesforce is slow (the lwc frontend I mean), and has legacy (aka governer) limits. E.g. you can't have synchronous code run for more than 10 seconds, you can't update more than 200 records in a standard transaction, the query language has only very basic joins, and much more.
If you can build a crm without these limitations, why not get your 80% without the limits?
Because Salesforce is already tightly integrated into many companies workflows, and already has incredible mindshare? And for the majority of conpanies, those limitations are just nuisances, not dealbreakers?
Mind share isn't necessarily an issue when you build a platform based on standard tools (e.g JavaScript, graphql, etc.).
In my experience those limitations are not just nuisances,they are expensive. They require a lot of custom work and and less reliable since you're leaving what's well known and supported. For example, many companies hit the "100 active concurrently scheduled jobs" limit very quickly. Then they need their own scheduler, or deal with the consequences of stale data.
Those limitations are not just nuisances, they change real business workflows.
Yes, there are definitely good business justifications for choosing Salesforce, but I definitely think there is real business value to be found in improved CRM systems.
Salesforce gets the ubiquity the same way that Wordpress does: randos can copy some code fragments off of a website and stick it into a file/textbox, and get new functionality.
So... Twenty, hire one person whose job it is to layer AWS Lambda over your system :)