Twenty, a modern CRM alternative to Salesforce(twenty.com) |
Twenty, a modern CRM alternative to Salesforce(twenty.com) |
Otherwise the switchting-costs are probably too high for most companies.
I have a number of simple database apps/sites I want to build that don’t warrant dedicated CRUD apps.
What most startups / new products fail to realize is that you can get 80% of your needed CRM capabilities just from a shared Google Sheet.
But that last 20% is brutally difficult and long.
It might be:
- sales rep compensation
- customer billing
- contracts management
- eSign
- usage reporting
And much much more.
Salesforce has most of this. And for what they don’t have, they created their platform so 3rd party’s can add it.
You’re not competing in having a “CRM alternative”.
You’re competing on having that long tail of 20% other functionality that’s core and critical.
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.
If you can build a crm without these limitations, why not get your 80% without the limits?
Any HN submission with the word "modern" in the title should be shit-canned.
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 :)
(We too are in the "let people execute their code on our servers" space; providing a flexible data model seemed to have been key)
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.
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.
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'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.
That's what I read it as the first time through. How annoying.
Programming And Workflows are keys
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.
Never found anything more suitable, though.
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].
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?..
pretty cool but obviously an automation native platform would be cooler and I think Attio is the contender for this
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."
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.
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.
Now fighting to keep Salesforce out of company. Shiny RFP’s of a horizontal service that doesn’t do much that well but appeals to execs.
The future is bright elsewhere
Does the $9/user/month plan exempt paying self-hosted users from those requirements?
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).
Which could in turn "infect" your core offering to now become AGPL (and now you're having to release your core product IP to the public).
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.
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!
User permissions: https://github.com/twentyhq/twenty/discussions/209
Other than that, I'd expect segment-based permissions (sales team/territory etc) as a minimum.
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
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
zapier is a good place to shop for these
I've been using it for close to ten years and can't imagine using another CRM.
I believe they were an early YC company as well.
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.
I'm curious to understand more.
Do you mean you're non-traditional in how you track Pipeline and working a customer through your sales funnel to Close?
(which I am struggling to understand what could be non-traditional about that)
Or are you referring to something else?
Genuinely curious, which is why I ask.
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 :)
That's what your standard business says and it is often business with bad practices that say that
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.
While being able to update the platform seamlessly without breaking that logic.
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.
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 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.
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....
I, and many others, would jump to build on basically any tool that facilitated those relationships.
* 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.
Language on their homepage: The #1 Open-Source CRM Modern, powerful, affordable platform to manage your customer relationships
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.
This is what the default crm looks like: https://demo.iceburg.ca/
Here are some samples I generated:
Gourmet Coffee Enthusiasts CRM
Bee Keeping CRM https://beekeeping.iceburg.ca
You can also manage an existing database as a CRM.
Here is a default wordpress database crm.
Live wordpress site: https://wordpresssite.iceburg.ca/
Open Source. Check it out. https://github.com/iceburgcrm
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
LLMs might tip the calculation of buy v build enough that "roll your own" becomes the standard for most business apps.
Don't forget to hire/contract experts to admin those """off the shelf""" solutions!
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!
[^2]: https://fortune.com/longform/disrupted-excerpt-hubspot-start...
You can customize views and reports. To the point you can make it do stuff like be a kanban board or blog. It’s really flexible. The “build a portfolio” is actually using the CRM (IIRC). https://trailhead.salesforce.com/content/learn/trails/build-...
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.
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.
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.
https://c8.alamy.com/comp/B083YP/female-secretary-or-assista...
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.
I absolutely love Windmill. The ability to stitch scripts together into workflows is great.
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.
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.
Also how does one restrict to a particular tenant
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.
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.
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.
The trouble that you’ve probably felt is CRM are sold to sales exec and as such, focus on sales exec needs.
You’d be better served not with CRM, but a personal contact management system.
Something like https://www.monicahq.com/
There are a few built on salesforce but there are others that are standalone, and they all implement CRM in some way.
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.
Do you host it yourself, what database is used?
I've done some work for a homeless advocacy group that uses Salesforce, it keeps track of donors as well as information on clients.
> 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.
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.
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.
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.
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.
You're comparing apples and oranges.
Google documents well why they forbid AGPL https://opensource.google/documentation/reference/using/agpl...
Also there are plenty of profitable software with AGPL licenses, some even get acquired by public companies [1].
[1] https://www.rapid7.com/about/press-releases/rapid7-acquires-...
