You upgraded to HubSpot's Professional tier six months ago because the team needed automation. Last month the invoice arrived, and someone did the math: you're paying more for your CRM than for your hosting, your error monitoring, and your CI/CD pipeline combined — and that's before the next seat you're about to add.
That's the moment founders and CTOs start Googling "open-source CRM." This article is what I wish existed the last few times I had that conversation.
One scope note upfront. I'm writing from my experience building integrations, automation pipelines, and custom data layers for small-to-mid SaaS products and e-commerce businesses. I have hands-on time with most of what I'll describe below, but I haven't run each of these in production at scale. Where my experience is thinner, I'll say so.
This article addresses the SMB and mid-market product-led world specifically — teams in the 5 to 200 seat range, with internal engineering, where the CRM is one part of a broader product or sales stack. It is not aimed at: enterprise procurement processes with multi-quarter vendor selection, call-center operations where ACD/IVR integration dominates the requirements, regulated industries (healthcare, insurance, telecom) where compliance certification of the CRM vendor itself is part of the buy decision, or ERP-CRM hybrid deployments. Those situations have a different calculus, and the options below are not the right starting point for them.
Why People Are Looking in 2026
Per-seat pricing is the obvious trigger, but it's rarely the only one. The complaints I hear most often in practice:
Per-seat costs that scale badly. Most commercial CRMs charge per user per month. That model is fine when you have two salespeople and 5,000 contacts. It becomes painful when you're adding a CS team, a few account managers, and some ops people who need read access — and suddenly you're paying for fifteen seats of a plan built for pipeline management, most of which those people never use.
Schema rigidity. HubSpot, Pipedrive, Salesforce — these are built around a fixed object model (Contacts, Companies, Deals, Tickets). If your business model doesn't map cleanly onto that model, you end up in one of two places: hacking your data to fit the CRM's shape, or building a separate database that holds the data the CRM can't, then syncing between them. I've seen both. Neither is satisfying.
Integration ceilings. The built-in integrations cover the popular platforms. When you need something custom — a webhook to a bespoke logistics system, a sync with an in-house billing engine, a data feed from a government API — you're either paying for an enterprise plan that unlocks the API, or you're fighting rate limits and underdocumented endpoints. In pikkuna.fi, most of the complexity wasn't in the storefront; it was in the integration layer. A CRM with full API access and no per-call pricing would have simplified that significantly.
Data sovereignty and compliance. This comes up more often in EU projects than US ones. Where is your customer data? Who can access it? Can you export it completely and delete it completely? GDPR compliance is easier when you control the database.
AI and data access. This one is fashionable, so it's worth being careful.
The honest version: if you plan to build anything that reads or writes customer data programmatically at scale — automated enrichment, internal semantic search, automated workflows — direct database access is much easier to operate than threading everything through a vendor's API tier. That's the real argument.
Building "RAG on the CRM" is a separate project. Permissions-aware retrieval (an embedding doesn't carry an ACL), PII boundaries, embedding refresh on data change, hallucination cost in customer-facing contexts — none of these are solved by self-hosting. Headless CRM doesn't address those problems. It removes the rate-limit ceiling underneath them.
What "Headless" Actually Means Here
A clarification before the options. "Headless CRM" here means something specific: a CRM where the data layer and the UI layer are decoupled enough that the data layer can be used independently — through APIs, webhooks, direct database access, or all three.
This matters when the CRM is one component in a broader system, not the system itself.
The dimensions worth checking on any candidate:
- API surface. REST, GraphQL, or both. How complete it is — can everything the UI can do be done through the API, or are there UI-only operations? Twenty exposes GraphQL that mirrors the application; EspoCRM has a REST API that covers most of the entity manager.
- Webhook reliability. Outbound webhooks on create/update/delete events are how CRMs participate in event-driven architectures. Retry semantics, delivery guarantees, and signature verification matter as much as whether webhooks exist at all.
- Schema evolution. How custom objects, custom fields, and relationships are added — through code, through UI, through migrations — and what happens to existing data when the schema changes. EspoCRM's entity manager is the most explicit example of this; Twenty's metadata model handles it differently; on a custom Postgres build, you own it entirely.
- Extensibility model. Plugins, modules, server-side scripts, or "fork the repo." Each has different operational cost. Fork-and-modify is fastest short-term and expensive long-term.
- Multi-tenant isolation, if relevant. If you're embedding CRM functionality into a product you sell to multiple customers, tenant isolation at the data layer is a separate concern from anything the CRM advertises.
None of the options below score full marks on every dimension. The right question is which dimensions your situation actually depends on.
The Main Open-Source Options
Twenty
Twenty is the option that gets the most attention right now, partly because it's visually polished in a way that older open-source CRMs are not. React frontend, GraphQL API, Postgres underneath. It's modeled explicitly as a HubSpot alternative, and the UI reflects that — pipelines, contacts, companies, all the familiar objects.
The appeal is real: modern, self-hostable, active community, readable codebase. If you want something that feels like a SaaS CRM on your own infrastructure, Twenty is currently the most convincing option in that space — and I should be explicit that for the kinds of small product-led teams I most often work with, this is where my recommendations tend to land first. Readers in other situations should treat that as a bias to discount.
The ceiling is maturity, and it cuts in two directions. Features that are table stakes in commercial CRMs — advanced reporting, robust email integration, granular permissions — are present but rough, or on the roadmap. That's the visible part. The less visible part is that a fast-moving young product carries category-specific risk: schema migrations between minor versions, API shape changes, breaking plugin compatibility. Twenty is genuinely promising, but you are choosing it earlier in its lifecycle than you would choose EspoCRM or SuiteCRM. If your team's CRM usage is standard, that risk is manageable. If you have specific workflow requirements, run a two-week trial before committing migration effort.
Pricing model: free, open-source (MIT). They offer a hosted cloud version on a SaaS model if you don't want to self-host.
Who it fits: Early-stage product teams replacing HubSpot Starter or Pipedrive, comfortable with self-hosted infrastructure, don't need deep customization of the object model yet.
EspoCRM
EspoCRM is older and less visually flashy, but it's the one I've seen hold up best in situations that require genuine customization. PHP, GPL/commercial dual license, entity manager that lets you build custom objects and relationships through the UI without writing code. The underlying philosophy is different from Twenty: rather than being a clean replacement for a specific SaaS CRM, it's a platform you can shape to your domain model.
If your business doesn't fit neatly into the standard Contacts/Companies/Deals model — say, you're running a B2B marketplace, or a services business with a project-based workflow, or you have custom objects with complex relationships — EspoCRM's entity manager is genuinely useful. You can define new objects, set relationships, build custom fields, and wire up workflows without dropping into code for every change.
The trade-off is the surface. The UI is functional and not embarrassing, but it doesn't have the surface polish of newer products. If your team evaluates tools partly on visual polish — and some teams do, fairly — EspoCRM will feel like a step backward from HubSpot or Pipedrive.
The flip side is worth being honest about: EspoCRM is mature, well-documented, has a long-stable plugin ecosystem, and a predictable upgrade path. For a system that will hold customer data for the next five years, those qualities frequently matter more than whether the frontend is React. "Boring stack" is a feature in this category, not a defect.
Pricing model: Community Edition is free/GPL. Professional and Ultimate tiers are commercial licenses. Self-host both; the difference is features (advanced reports, scheduled workflows, portal, etc.).
Who it fits: Teams with domain-specific data models, agencies managing complex client relationships, businesses that have already found commercial CRMs too rigid and have the technical capacity to operate a self-hosted PHP application.
Krayin
Krayin is a Laravel-based CRM from the team behind Bagisto (the e-commerce platform). Modern stack, clean UI, reasonably active development. It covers the basics well: leads, contacts, organizations, deals, email, products.
My honest assessment: it's a solid choice for teams already running Laravel infrastructure who want a CRM that fits their stack. The integration story with a Laravel backend is as frictionless as it gets. Outside that context, I'm not sure it has a compelling reason to choose it over EspoCRM for customization depth, or over Twenty for modern polish.
Who it fits: Laravel shops, dev agencies building CRM functionality into client portals, teams who want a CRM with an API that feels familiar.
NocoDB as a CRM
NocoDB is an open-source Airtable alternative — a spreadsheet interface on top of a database. Some teams use it as a lightweight CRM, particularly in earlier stages when "CRM" mostly means "a shared table of contacts with some metadata."
The argument for it: if you already have data in a Postgres or MySQL database, NocoDB can give your team a decent UI over that data in a few hours. No schema design required. Filtering, sorting, views, forms — it's there.
The argument against it: it's not really a CRM. It's a database UI. You won't find pipeline management, deal stages, activity tracking, or email integration unless you build them yourself. The moment your sales process needs more than a filtered table, NocoDB stops being a CRM and starts being a workaround.
Who it fits: Very early teams (pre-product-market-fit) who need to track a small number of leads and are already using Postgres. As a permanent CRM choice, I'd be skeptical.
SuiteCRM
SuiteCRM is the open-source fork of SugarCRM. Enterprise feature set — campaigns, cases, contracts, reports, dashboards, the works. If you need the breadth of a large commercial CRM with full self-hosting, SuiteCRM covers it.
The honest assessment is bifurcated. The codebase is old and complex; the UI is dated; customization requires understanding an architecture that predates modern frontend frameworks. Those are real costs. But SuiteCRM is also battle-tested in ways the newer options aren't yet: there are integrators who have specialized in it for over a decade, predictable upgrade behavior, mature workflow and reporting engines, and a feature breadth that smaller projects haven't reached. For a team optimizing for "this still works the same way in five years," that maturity is worth more than a contemporary UI.
I'd consider SuiteCRM if I needed the full enterprise feature set, had someone who could own the installation and maintenance, and valued predictability over polish. For most of the small-to-mid product teams I work with, the overhead isn't justified. For larger or longer-horizon deployments, dismissing it on aesthetics is a mistake I see often.
Who it fits: Nonprofits, larger organizations migrating off a commercial CRM with a complex feature dependency list, teams with dedicated technical staff who can manage the infrastructure.
Ecosystem Risk Is Real Too
Open-source doesn't automatically mean low vendor risk. It means the risk has a different shape.
Commercial CRMs can raise prices, deprecate APIs, get acquired, or change terms. Open-source CRMs can lose their maintainer, run out of funding, fragment into competing forks, or quietly stop receiving security patches. The failure mode is different. It is not absent.
Things worth checking before committing migration effort:
- Bus factor. How many people actually merge meaningful changes? If the answer is "one or two," that's a signal — not a deal-breaker, but a factor in your sizing of operational risk.
- Funding model. Donations, dual-license, VC-backed open-core, foundation-stewarded. Each fails differently. VC pivots; donations stall; open-core gradually paywalls what you actually need.
- Plugin and integration ecosystem. A CRM is half its plugins. EspoCRM and SuiteCRM have ecosystems measured in years; Twenty's is still forming. If a plugin you depend on is maintained by one person, that's a separate bus factor.
- API stability commitments. Is there a deprecation policy? Are breaking changes announced in advance? Or do major versions casually rename endpoints?
- Forks of dead projects. SuiteCRM exists because SugarCRM stopped open-sourcing. Knowing the origin story of a project tells you something about how it has handled stress.
None of this is a reason to default to a commercial CRM — they have their own failure modes, often less visible. It's a reason to size your migration risk based on actual project health, not the assumption that "open-source" automatically means "safe."
DIY on Supabase/Postgres: When It's Actually Reasonable
This option gets dismissed too quickly, and it also gets chosen too quickly. The reality is situational.
slug="api-integrations"
text="Evaluating a CRM migration? The hardest part is usually the integration design — getting the new system talking correctly to everything around it. That's the work I take on."
/>
Building a minimal CRM layer on Supabase or a Postgres database makes sense when:
- Your domain model is genuinely unusual, and every existing CRM would require significant mapping work anyway
- You already have the customer data in your database, and a CRM is mainly adding a UI and some workflow logic over data that already lives there
- The feature set you need is narrow — pipeline tracking, a few custom fields, activity logging, maybe some basic automation — and you're confident it will stay narrow
- You have the engineering capacity to maintain it, and the team understands that "we built it" means "we own it indefinitely"
It's not a reasonable choice when:
- Your sales or CS team needs a polished mobile experience
- You need email integration, calendar sync, or complex reporting out of the box
- Nobody on the team has time to maintain it — the CRM will be correct for about six months and then drift
- You're building it to avoid making a decision, rather than because it genuinely fits better than the alternatives
In pikkuna.fi, the order management and customer workflow layer is essentially a custom CRM built on top of the existing data model — because the domain (multi-market B2B e-commerce with complex automation) didn't fit any standard CRM's object model without significant contortion. That was the right call there. It would have been the wrong call for a SaaS startup with a conventional sales pipeline.
The cost comparison is also not as clear as it looks. You save on per-seat fees. You spend on development time, hosting, and ongoing maintenance. For a standard sales workflow, in most cases I've seen, the custom build ends up costing more over a two-year horizon unless you have strong engineering capacity and genuinely unusual requirements.
The more important failure mode is organizational, not technical. An internal CRM gradually becomes a second product without product management. New requests arrive from sales, support, finance, and the founder. Custom fields proliferate. Workflow shortcuts get coded in by whichever engineer was free that week. Business logic accumulates with no owner deciding what belongs and what doesn't. After eighteen months, the system holds a lot of undocumented organizational knowledge and no one can confidently change anything. This is how internal CRMs die — not because the database breaks, but because no one is doing the product management that a commercial CRM vendor does on your behalf, and the organization eventually notices.
If you go this route, someone needs to own that role explicitly. Not maintain the code — own the scope.
Decision Framework
Before choosing, answer these:
How many people actually need CRM access? Rough order-of-magnitude TCO ranges to anchor the math (numbers are illustrative, not quotes — your situation will differ):
- 10 seats: Commercial SaaS at €30-80/seat/month lands around €4-10k/year. Self-hosted Twenty or EspoCRM Community: ~€500-1.5k/year in infrastructure plus the time of whoever maintains it. Below this size, the migration project usually costs more than several years of the SaaS subscription. Stay where you are unless schema or integration limits are the actual problem.
- 50 seats: SaaS €20-50k/year vs self-hosted €2-5k/year in infrastructure, plus 0.1-0.3 FTE in maintenance for a serious deployment. This is the band where per-seat pricing typically becomes a real conversation, not a hypothetical one.
- 200 seats: SaaS €80-250k/year. The savings argument is obvious; the operational argument is the question. At this size you almost certainly need someone whose job includes the CRM — either an internal ops person or a vendor relationship.
The DIY route (Supabase/Postgres + custom UI) skews these numbers heavily: low recurring cost, high upfront cost, ongoing maintenance load that does not show up on any invoice.
Does your business fit the standard object model? Contacts, Companies, Deals, Activities. If yes, the entity model is not the bottleneck — but that doesn't mean every CRM is equivalent. RBAC depth, audit logging, workflow engine capability, SLA automation, reporting and forecasting, and approval chains differ substantially across products even when the object model is identical. If your team has real requirements in those areas, evaluate them explicitly. If your object model genuinely doesn't fit, that's the primary reason to consider open-source.
Who maintains it? A self-hosted CRM is infrastructure you own. It needs updates, backups, monitoring. If nobody on your team can credibly own that, a managed option (cloud Twenty, or staying with a commercial CRM) is probably cheaper than the ops burden of a misconfigured self-hosted installation. For teams without a dedicated CTO, a fractional CTO engagement can be the right structure to own these architectural decisions without a full-time hire.
What integrations do you actually need? List them out. Check whether your shortlisted options have those integrations out of the box, or whether you'd be building them. Custom integrations are a real cost.
What does your data residency situation require? EU companies with specific GDPR obligations may need data in a specific region. This can narrow the options quickly.
What does "good enough" actually mean for your team? Sales teams are particularly opinionated about their CRM. If they hate the tool, they won't use it, and a CRM that isn't used is worse than no CRM. Get the people who'll use it daily into the evaluation.
What I Usually End Up Recommending
When per-seat cost is the trigger and the feature requirements are standard, Twenty usually goes on the shortlist first — closest to a drop-in replacement for early-stage commercial CRM usage, and the hosted version sidesteps self-hosting complexity. When the object model is the real problem, EspoCRM's entity manager earns its place despite the aesthetic gap. When the deployment horizon is long and the team values predictability over polish, SuiteCRM stops looking dated and starts looking sensible.
What I resist: recommending a custom build as a way to defer a decision, or recommending a migration as a way to solve a process problem that would follow the team to any CRM they chose.
When Headless CRM Is Not the Answer
This is worth saying plainly, because the framing of this article could suggest that open-source or self-hosted is always the more sophisticated choice.
It isn't. HubSpot and Pipedrive exist because a lot of sales teams have standard workflows that these tools handle well. If you have a conventional B2B sales pipeline, a small team, and you're under a few hundred dollars per month in CRM costs, the ROI on a migration project — even to a free tool — is questionable. A migration takes engineering time, produces user friction, and introduces operational risk. It's worth doing when there's a real problem being solved.
The right time to seriously evaluate an alternative is when: you're feeling the per-seat ceiling as team grows, you've hit a schema limit that's causing real workflow problems, or you need data access that your current vendor restricts. If none of those apply, the grass may not be as green as it looks.
One Last Thing
Most CRM decisions get framed as software choices: which tool, which stack, which license. They rarely fail for software reasons.
They fail because the team wanted clarity about its own sales process and decided to buy it by changing tools. They fail because nobody owned the scope of an internal build. They fail because a migration was used to delay a conversation about who owns the customer relationship and what that actually means in this company.
A CRM does not produce that clarity. It records the clarity you already have.
Pick the tool whose constraints match the clarity you can produce. That's the decision. Everything else in this article is execution detail. If you've already decided to move, the practical migration is covered in migrating from HubSpot to a custom CRM.
items={[
{
q: "What is a headless CRM and how is it different from a regular CRM?",
a: "A headless CRM decouples the data layer from the UI layer, so you can access your customer data directly via API, webhooks, or database queries — not just through the vendor's UI. Twenty and EspoCRM are headless-capable open-source options. HubSpot is not headless: your data lives on their servers and access goes through their API tier, which can impose rate limits and pricing tiers.",
},
{
q: "When does it make sense to migrate from HubSpot to an open-source CRM?",
a: "Three triggers make the case: per-seat costs are growing faster than revenue, your domain model does not fit the standard Contacts/Companies/Deals object model, or you need data access that HubSpot restricts behind enterprise tiers. If none of these apply, the migration project often costs more than a few years of the SaaS subscription. Full migration guidance is in the article on migrating from HubSpot to a custom CRM.",
},
{
q: "Twenty vs EspoCRM — which should I choose?",
a: "Twenty is the right first look for early-stage product teams replacing HubSpot Starter or Pipedrive. It is visually polished and the fastest path to a familiar CRM experience on your own infrastructure. EspoCRM earns its place when your domain model is genuinely non-standard — custom objects, complex relationships, multi-level workflows — or when you need a system that will be stable for five-plus years without surprise migrations.",
},
{
q: "Is building a custom CRM on Postgres a realistic option?",
a: "It is realistic when your data already lives in Postgres and the CRM mainly adds a UI and workflow logic on top of it, or when your domain model is so unusual that every off-the-shelf CRM would require significant mapping work anyway. It is not realistic when your sales team needs a polished mobile experience, when nobody on the team has time to maintain it, or when you are building it to avoid making a decision.",
},
{
q: "What are the real risks of open-source CRMs that vendors do not mention?",
a: "Open-source does not mean zero vendor risk — it means the risk has a different shape. Projects can lose maintainers, run out of funding, or gradually paywall what you actually need in an open-core model. Check the bus factor (how many people merge significant changes), the funding model, and API stability commitments before committing migration effort.",
},
{
q: "How much does a CRM migration project typically cost?",
a: "This varies significantly by data volume, custom objects, and integrations. The TCO comparison is often less clear than it looks: you save on per-seat fees but pay in development time, hosting, and ongoing maintenance. At 10 seats, migration almost always costs more than several years of the SaaS subscription. At 50+ seats, the math starts to work in favour of self-hosting. I cover the rough numbers in the decision framework section above.",
},
]}
/>
If you're evaluating a CRM migration or building a custom workflow layer for your product, the hardest part is usually the integration design — getting your new CRM to talk correctly to the systems around it. That's the kind of work I do in API & integrations engagements. If the question is more fundamental — whether to build, buy, or migrate, and what that actually costs — a technical consultation is probably the right starting point.
Top comments (0)