Launch HN: Okapi (YC W24) – A new, flexible CRM with good UX
We’re Ulysse and Ned from Okapi. We’re making a modern CRM. It's kind of like if Airtable/Notion built Salesforce today. https://okapicrm.com
When I was fresh out of college, working for startups, Salesforce was this big mystery to me. It's the perpetual second screen for everyone in sales. They were building this gigantic obelisk downtown. What was this thing? And why did every salesperson I knew seem to live in it all day, and yet hate it so much?
Turns out Salesforce is basically PhpMyAdmin for salespeople. It's just basically two things:
1. A really generic database, and a UI for CRUDing your data.
2. An API and ecosystem of integrations.
In other words, it's the back-office CRUD app to end all back-office CRUD apps. People call the result a "CRM" (Customer Relationship Management).
Salesforce is slow and clunky. And that doesn’t matter because people don’t buy Salesforce to be delighted. They buy Salesforce to avoid being screwed over.
SObjects are how Salesforce does that. It’s the best idea Salesforce ever had: make everything in your product be built upon a generic data layer that your users can configure. Just like how you can add a new sheet or column in a spreadsheet, in Salesforce you can add new objects and fields. You can CRUD, report on, and do automations on top of custom data in exactly the same way you do it for built-in data.
The graveyard of wannabe Salesforces is littered with people who forgot about this key insight.
We think the way you win in CRM in 2024 is by keeping the flexibility of SObjects, and then tacking on modern UX. That first part takes engineering discipline, but the second part is much easier than Salesforce had it 25 years ago. Just about every part of a modern SaaS product has dozens of vendors that do most of the work for you.
We're really excited to get feedback from HN on what we have. Here’s a video demo: https://www.youtube.com/watch?v=4uRBf_9CRyM - and you can try it yourself:
Email: hn.login.user@okapicrm.com
Password: sk9ueEAfhXP9j4cuxLCVmw7.
You can test out our email integration, send an email to: hn.demo@okapicrm.com
And see that email (up to ~10min latency): https://app.okapicrm.com/objects/emails/records
We’re very eager for your honest feedback. What do you think we're missing? One thing we can’t decide if it’s a need-to-have is Apex -- is having in-transaction custom scripting really necessary for a CRM? Or is that just something they tacked on as Salesforce became more of an app platform and less of a focused CRM product?
105 comments
[ 3.6 ms ] story [ 183 ms ] threadEveryone is using it and they all look the same
So far, the main difference is that Okapi can be even simpler than Attio if you'd like it to be. There are no mandatory built-in objects, and no enrichments/automations/etc that you can't disable. You can KISS your sales process as much as you like.
To that end, we've also been eschewing self-service onboarding. We just set up customer's CRMs and import their data for them, shooting for the simplest setup they can get away with. The software is generic, and we make it concrete for customers by hand.
Our long-term differentiation will be more obvious as we mature the product and distribution model.
We're working on a simple way to do deal->email association. Right now you can only do deal->company->email, so if you have concurrent deals on a company there's not a great way to disentangle them.
You got thoughts on how you'd want that to work?
Big companies have different departments. You could have a deal with department X at TargetCo and department Y. Generally those are different people (and emails) at each of those departments. So you associate email to the deal based on what email it's copied to.
Just use emails to link to deals. Forget about company.
Company association is useful. But it needs to be a historical association. Example Jonny works at MSFT now. But used to work at FB. Jonny could help you win a deal with FB even if he doesn't work there now.
It sounds like your business strategy is 'remove legacy code.' I don't hear anything about how you will address network effects or inertia, or which niche user are you solving a problem for.
Good luck.
We support syncing Outlook email/contacts into Okapi. Definitely agree that outside of tech, Microsoft's stack is predominant.
We've considered working on a chrome extension to help sales people pipe data into our product, but we haven't thought surfacing CRM data to salespeople in other apps.
I played with the demo for a couple of minutes- one thing I noticed was that to add a field, you have to go up to the drop down menu in the top right and select add field- I would expect to see an "add field" button below the (initially empty) list of fields on an object. Hotkeys would also be really nice at some point as you develop the app. Probably just really early in your development to refine these things.
You mention your path to success being a "modern UX" and I think that is great, if by "modern UX" you mean (at least in part- a major part) "much faster and more responsive than Salesforce". Maintaining the flexibility while also keeping it easy to use and fast is a triple combination of power.
I expect performance and developer experience to evolve as points of competitive differentiation as we mature. We're still too early to make those claims defensibly.
I totally agree the object management UI is too clunky right now. I want to redo that set of pages, they were the first ones we shipped. Not gonna lie, idk if anyone except me and Ned are really pining to learn hotkeys for managing object schemas, since in practice we're the only ones doing that on a regular basis -- we do initial setup on behalf of our customers.
Yeah, I consider latency part of UX. We're doing some somewhat fancy stuff to reliably replicate every record into a couple of stores, each of which is optimized for different access patterns (search, get latest by ID, etc.). The big central Postgres(TM) is mostly there to be authoritative and to transactionally maintain invariants in the system.
When I, as a perspective customer, read things like this, it makes me question if I can trust you with my data or your platform long term.
What is your technical expertise and what other similar systems have you built? I can’t seem to find it on the site.
I love to see anyone taking on salesforce.com, but your product so far is way too barebones. It reminds me of something I'd get from just using some admin UI for a database.
I was a salesforce technical architect and consultant for a number of years (hated it.) and what I've seen is that some of the first things people look for are reports, dashboards, workflows, integration. A lot of people think their sales process is super unique and want to see a path of implementing it in a system and that includes integrating it with a bunch of other systems already in place.
For smaller companies, sourcing leads, creating and tracking email campaigns, is probably the first thing they look for.
Some feedback for your website:
* gifs/videos take a while to load and stay blurred
* The linkedin example is great, show more like this
* Ability to add custom fields/objects is expected, doubt anyone would be impressed by that
* Show some canned dashboards and reports on the data
For sourcing and campaigns, our initial plan is a two-way Apollo integration. Not sure if you have thoughts on the necessity of doing everything in-house (the Hubspot approach) or just focusing on integrating with the best tools (the Salesforce approach).
Your feedback on the website is well taken. We've got a lot of work to do there.
[0] https://github.com/carboneio/carbone
No decisions yet on who best fits our needs, so thanks for raising Carbone; it wasn't on our list yet.
Those small teams/companies basically want a simple Hubspot, not salesforce, but a lot of times, they don't really know the difference. Something that can take Apollo leads, build some "simple" email campaigns [1], some landing pages [2], track one-off emails and report on all that for cheaper than the $25k/yr or whatever hubspot charges would be a great tool. I know, not exactly a CRM, but people call it that.
I don't think it matters if you integrate other providers or build it in, but having an easy setup where users don't have to go sign up, manage and integrate with a bunch of other services could help you get the small/startup space.
[1] Lots of things to deal with if you're taking on the email sending & tracking part, automated clicks, safari privacy, etc. [2] This is a can of worms, but being able to build simple landing pages for people to click on from an email is pretty important.
You're 100% right.
We're missing a bunch of stuff simply because we're early :)
Regarding custom objects and fields, I agree this is not very interesting when compared against Salesforce, but these things actually aren't common in the products we can currently compete with! These are typically low-end, self-service products designed for simplicity and don't afford their users much freedom.
In this sense, we've been able to offer some of our early customers the flexibility of a SFDC product without all the other stuff. A decent chunk of people want exactly that.
A few things on the roadmap include:
* Reporting
* Custom views
* Open API
* Built-in automations (right now we piggyback on Zapier)
All this stuff will take a long time to get right
hn.login.alt1@okapicrm.com
hn.login.alt2@okapicrm.com
hn.login.alt3@okapicrm.com
All have the same password as in the original post: sk9ueEAfhXP9j4cuxLCVmw7. (include the trailing period)
We rely on GMail or Outlook's spam and checks. We only sync emails that made it to your non-spam inbox.
Salesforce, with its batch loads, open api spec, soap/rest api and 'use mulesoft' approach makes this pretty painful, and quite expensive.
The dream, at least among folks I work with, is for a single pane of glass where salesforce provide contact and case management, and the internal systems provide a source of truth and the apis or screens to fix problems or complete tasks
We are definitely looking to make our API public. We've built our core data model in such a way that business users can't accidentally break API users by, for example, making backwards-incompatible changes to their objects. It baffles me that everyone else in the space gets this wrong. But still, I want to feel really good about making an API that can stick around a long time before telling people to use it to run their business, and we're just not there yet.
Small bug report: when editing the dropdown, current entries have "API Name" disabled (this is normal), but the value is changend automatically when editing the "Display name". The page errors out (400 error for UpdateObject).
When using devtools and editing "API Name" to stay the same, everything works.
This is the lowest engagement I've seen for a launch HN. It's because most people are too kind to give you the honest feedback that this seems extremely undifferentiated. It made me think of a CS-class project.
Every significant CRM has custom objects, in-place editing UI, and custom fields. Most have email integrations. Look at Monday CRM for example - it has a very powerful no-code automation engine, and you can upload custom react components. The biggest competitor to Salesforce CRM is HubSpot.
I really, truly hate to be negative but I think someone has misled you about the state of this particular market.
I went back and forwards on this because I don't want to discourage you. Sorry if this seems harsh or unhelpful.
Did any user tell you that they have the problem you are solving?
The list didn't include the three mentioned in the comments here (Attio, Twenty, Monday). My strong suggestion is that you look at the current entrants and try to find some differentiation.
Response from ChatGPT:
"CRM systems with the capability to support custom data objects are designed to offer businesses the flexibility to tailor the CRM to their specific needs, such as tracking unique customer data, industry-specific information, or customized business processes. Here are ten CRM systems known for their ability to support custom data objects:
Salesforce: Known for its high degree of customization, Salesforce allows users to create custom objects to store specific business data and relate to other records within the system.
Microsoft Dynamics 365: Offers extensive customization capabilities, including the creation of custom entities (data objects) that can be integrated seamlessly with the rest of the system.
Zoho CRM: Provides the ability to create custom modules that can be designed to capture and manage business-specific information.
HubSpot CRM: Allows the creation of custom objects to store and organize data that doesn’t necessarily fit into the standard objects like contacts or companies.
Oracle NetSuite: Features a flexible platform that includes the ability to create and manage custom records tailored to your business needs.
SAP CRM: Part of the SAP Business Suite, SAP CRM offers the flexibility to extend its core functionalities with custom objects to meet specific business requirements.
Pipedrive: Known for its user-friendly interface, Pipedrive also offers custom fields and, in some plans, the ability to create entirely custom data objects.
SugarCRM: Provides a highly customizable platform where users can create custom modules and fields to adapt the CRM to their business processes.
Insightly: Offers custom fields and records, allowing users to tailor the CRM system to better fit their specific business needs and workflows.
Freshsales (Freshworks CRM): Allows for the customization of the CRM with custom fields and modules, enabling businesses to track unique data points relevant to their operations."
The low effort required to find endless examples was the point.
"How to Start Google"
It makes salient points about what is needed to venture forth and create a "startup". It seems pertinent here because your comments about this project seems to not really meet the criteria, and calls into question whether the salients points from the essay apply here. Good topic for discussion.
I think what happens is people hit this "here's what you need to do to start a company" and like 40% of all founders see opportunity in those basics and build an email, CRM, survey, project management, etc. tool because it feels bad to pay high prices for something you could build themselves.
The engineering equivalent of this is an issue tracker, JS framework or "we simplified kubernetes".
I wouldn’t get too distracted by reporting - SF classic had the absolute worst reporting engine for decades and they still sold millions of licenses all for the ability to click-to-configure. Pure sales teams use listviews more as a ‘who do I call today?’ list based on rankings and last interaction dates. Serious CRM enterprises have their own report infrastructure and don’t use the built in.
Congrats on the launch! couldn’t login to the demo on mobile but will try from a desktop. All the best.
I'm curious about the setup process. The key advantage of something like this over a Salesforce would presumably be the ease of onboarding for SMBs. I saw you comment that you guys are currently handling the initial setup though.
How do you think about your plans for making onboarding as easy as possible and potentially being completely self-serve going forward?
We're open to exploring self-serve, but realistically that's going to be really hard to get right. I'm imagining we may have templates that customers can choose from down the line, where they can one-click setup a CRM for their kind of business.
I have some QA feedback for some quirks I noticed and some potential feature ideas/requests:
1) On the companies list, it would be nice if you automatically grabbed the favicon.ico from the domain. It would be nice if you could tether fields together so information can be automatically derived from other fields. This could include an area for custom scripts to do this automatically.
2) While using the demo I was automatically logged out. I'm wondering if someone else logged in and then my session was killed? Also, when I was logged out, I was given a white screen of death when I clicked back on the history, but was given no redirect. E.g. pressing back sent me to https://app.okapicrm.com/objects/companies but I'm just stuck with a page with the title "Title" and an empty div[id="react-root"] node.
3) Because you end the password with a period, if I double click on the password and copy that, it will put the wrong password in my clipboard. I wasn't sure if this period was part of the password or not until I logged in and tried without the period
4) At first, it wasn't obvious the search feature was only available for the current page you were on. E.g. I tried accessing search on the reminders page, https://app.okapicrm.com/reminders, and I wasn't sure what was suppose to happen after I typed something in. There was no visual feedback that a search query was being processed, or had been processed. Once I tried it on another page was it clear that the search feature was searching for records visible on the current page. Also, because it is so quick, I wonder if this is purely a client-side search. If I have a Records page with a paginated number of records, will the search be able to find records which are not visible on the current page? If not, I would find this super frustrating as a user.
5) If I look at the details page for a company record, the fields for the domain and icon url are not links. i.e. on https://app.okapicrm.com/records/e8e09b41-25ab-4889-92bb-987... I cannot click on QAComet.com or the icon url.
6) I'm not sure I understand why fields which point to an archived record must be cleared. Could you keep those fields and just use some kind of visual indicator (such as a red highlight or background) to show the record being pointed at is archived?
7) When I clicked the archive button, there was no visual feedback the website was loading. It would have been nice to at least change the cursor over the modal to a "cursor: wait" while it was making the archive request.
Hopefully you find these points useful!
1. Definitely want to improve favicons. For deriving fields, we do have formula fields. Would love to show that to you, it's not obvious enough how to use to enable for this HN launch.
2/3. Sorry about that. This username/password approach for the HN launch is definitely a hack.
4. Right now, search is just on the current type of record you're looking at. I want to fix this, and I just haven't because I haven't made the UI for filtering what objects to search across. The backend is in place though. Glad it seems suspiciously fast! I can assure it's a real FTS talking to a database.
5. I want to fix this too. A way to make data of type "Link" for better UI treatment.
6. Archiving is meant for data that others shouldn't be looking at -- it's a staging ground for data. That's why you can't point into archived data. It's also a precursor for deleting data, and we want to guarantee no dangling references to deleted data.
7. Will fix this.
Feel free to shoot me an email (found in my profile) when you update the product, I'm curious about how the formula fields will work and what kind of interface I'll be given.
P.S. for 4, the speed very impressive!
Datadog isn't as slow, but it's loads 2.7MB of data. It's unusable on a 4G tethered connection (ie my car's hotspot).
I pray that you keep load times minimal. I see almost 1MB loaded over the wire for a list of 15 objects.
Also, your sidebar icons (Risks/Companies/etc) look too much hotkeys, I was disappointed when I couldn't navigate to a section by it's first letter.
Want to work on reducing bundle sizes. Just haven't gotten a chance to get to that yet. Totally agree that load times really matter here, I've been focused on that and still have a few ways to speed that up.
I will say though that the two pieces of software that we are discussing seem necessarily much more bandwidth and data heavy than a CRM. So there isn’t as much justification for large bundle sizes for a CRM in my opinion
Do you need Apex for that? God, please, no. Apex doubles or triples the cost of Salesforce, because you usually end up spending tens of thousands euro on some agency doing the customization. If you want to compete with SF, offer Java, JavaScript or TypeScript as lambda or managed microservice hosting with fast links to your db/api (and do it better than Heroku). The better are your integration options with custom code, the more attractive it will be for digital services and non-trivial use cases.
I would love to see proper communication management respecting user subscription preferences and consent. Maybe look at Braze for that. If you could handle the calls, both inbound and outbound, internationally and with power dialer that would be awesome.
When I talked about Apex, I really mean the "scripting language that sees data mid-transaction" aspect of the language. Sounds like you're not really seeing the value there either? I totally agree that good old webhooks or some other trigger is seems almost always good enough if the API is fast.
Appreciate the suggestions re: comms and consent management. We're still not sure how we want to handle dialers.
I do see value there as long as it is a general purpose programming language running in your sandbox and not something vendor-specific.
https://www.unhcr.org/us/news/stories/refugee-led-business-p...
https://www.okapi-oil.com/ (maybe not a startup)
(I built the Okapi Green Energy pilot minigrid funded by USADF in Kakuma)