Open-source CRM for SMBs: a safer SaaS alternative

An SMB founder looking for a CRM in 2026 quickly runs into an uncomfortable choice.

On one side, there are the classic SaaS products: HubSpot, Pipedrive, Salesforce and the tools that promise to structure sales, marketing and support. They are powerful, mature and well documented. But in many 5 to 50 person companies, they also become expensive, rigid and dependent on the one person who knows where to click.

On the other side, there is the temptation of vibe coding: asking a resourceful team member, a freelancer or a coding agent to "build our own CRM". The promise is attractive. A tool that fits the business exactly, without heavy subscriptions, unnecessary menus or vendor sales funnels. The problem is that a CRM is not a small isolated app. It is often the core of the customer relationship. If it breaks, loses data, handles permissions poorly or cannot be maintained over time, the business pays for it immediately.

I increasingly believe in a third path: start from a solid open-source foundation, then personalize it with AI-assisted code, automation and agents, without rebuilding everything from a blank page.

This is what I deployed on a client project around Twenty CRM: an open-source, self-hostable CRM extended with n8n workflows, AI agents and business assistants such as OpenClaw or Hermes. I will not share the client name or internal numbers. The purpose of this article is to share the decision framework: when to keep a SaaS, when to avoid pure vibe coding, and when building on an open-source foundation becomes the better compromise.

Why this matters now

This is not only a technical debate. It is also an economic one.

As of June 2, 2026, HubSpot remains a strong company. Its Q1 2026 release reported revenue growth of 23% year over year on an as-reported basis, 299,458 customers as of March 31, 2026, and a platform now positioned as an "agentic customer platform". In other words, the stock price decline does not tell the story of a company collapsing.

But it does tell us something.

On May 29, 2026, HubSpot's own historical lookup showed a closing price of 220.63 dollars. Barchart showed a 52-week high of 611.00 dollars, reached on June 5, 2025, and a 52-week performance of about -55.55% since May 30, 2025. Market data varies slightly depending on the source, but the order of magnitude is clear: the market is repricing some SaaS companies brutally.

I do not read this as "HubSpot is useless now". That would be simplistic.

I read it as a signal: investors increasingly question how much value generalist SaaS platforms can capture when AI, agents and assisted coding make business software easier to customize. If an SMB can connect its CRM to its workflows, generate its own agents and adapt its tool to its real process, it is less willing to pay heavily for a complex platform it only uses halfway.

The practical question becomes: should you still buy a large SaaS, build your own tool, or assemble a more sovereign solution on an open-source base?

Model 1: the classic SaaS

Classic SaaS is still often the right choice when the company wants to move fast, reduce technical risk and use ready-made features.

HubSpot, Pipedrive or Salesforce bring useful things:

a proven interface,
many integrations,
roles and permissions,
support,
documentation,
marketing, sales and support connectors,
dashboards,
reassurance for the team.

For an SMB with no CRM at all, choosing a SaaS can be much better than staying in Excel, Notion, Gmail and sales reps' memory. I do not want to pretend otherwise.

The problem appears after implementation.

At first, you configure a few pipelines, fields, lists, sequences and automations. Then the company evolves. Channels multiply. WhatsApp, forms, calls, emails, quotes, invoices, reminders, support, enrichment, reporting. Business exceptions pile up. Sales reps work around the tool. Data gets duplicated. Automations are no longer understood by anyone.

At that point, SaaS is rarely "simple". It becomes a specialty.

You then need an internal CRM manager, a HubSpot admin, a Salesforce consultant, a certified partner, a freelancer or an agency. This is not absurd. But for a 5 to 50 person company, it can create a heavy dependency: legally, the tool belongs to the vendor, but operationally, it belongs to the only person who understands the configuration.

So the cost is not only the subscription. The real total cost includes:

time spent configuring,
per-user licenses,
options needed for automation,
implementation services,
plan upgrades,
paid integrations,
configuration debt,
the workarounds the team invents when the tool no longer matches the field.

Classic SaaS remains relevant. But it should no longer be the default choice.

Model 2: the CRM vibe-coded from scratch

The second model is the opposite reaction: "We will build our own CRM."

With Codex, Claude Code, Cursor, Windsurf and similar environments, producing a first version of a business tool has become much more accessible. A good brief, a few screens, a database, authentication, two or three automations, and you can get an impressive demo within days.

For prototyping, this is excellent.

For running the customer relationship of a company, it is riskier.

A CRM is not only an interface with contact records and opportunities. It is a system of record. It must know:

who can see what,
who can modify what,
how to prevent duplicates,
how to trace changes,
how to import and export data,
how to handle automation errors,
how to secure API secrets,
how to back up and restore,
how to handle several users at the same time,
how to keep a reliable history,
how to evolve when the sales process changes.

Pure vibe coding often underestimates these topics because the demo does not show them.

The first version seems to work. Then sequencing problems arrive: a webhook fires twice, a reminder leaves before a status update, an agent creates a note on the wrong contact, a task remains blocked, an opportunity changes pipeline and nobody understands why.

Then come security issues. Who has access to the database? Where are API keys stored? Do logs contain customer data? Are roles enforced on the server or only hidden in the interface? What happens if a former employee keeps an access token?

Finally, there is maintenance. Code produced quickly can become difficult to resume. Initial prompts disappear. Conventions are not documented. The team member who "vibe-coded the CRM" changes role. The freelancer is no longer available. A coding agent can help, but it does not replace clear architecture.

Vibe coding is not the problem. The problem is confusing it with a product strategy.

Model 3: open-source base, AI customization, controlled production

The third path avoids choosing between a closed tool and a complete hack.

You start from an open-source product that has already solved some of the hard problems: interface, data model, authentication, permissions, API, CRM components, object logic, views, workflows and deployment. Then you customize where the company actually needs differentiation.

Twenty is a good example of this movement.

Its documentation presents Twenty as a third option between software that is easy to start but hard to change, and software that is flexible but slow to set up. The project highlights an open-source core, self-hosting, data export and an architecture technical teams can extend with React, TypeScript and PostgreSQL. The self-hosting documentation also emphasizes data ownership, compliance related to data residency and customization.

This is not magic. That is precisely why it is interesting.

With a foundation like Twenty, you do not rebuild a CRM from scratch. You use an existing base, then personalize:

business objects,
views the team actually needs,
fields that matter,
automation between CRM, quoting, invoicing and messaging,
AI agents that prepare actions,
approval notifications,
import and cleaning scripts,
connectors with existing tools.

In the client project I am referring to, the point was not to have "one more CRM". The point was to connect the CRM to a complete work system: automations, AI agents, an internal assistant, sales follow-up logic and the ability to evolve the tool without waiting for a vendor to add the right button.

This is the same type of architecture I described in my field report on AI sales call analysis with n8n and Twenty CRM. The CRM becomes an operational base. The value is created in the flows around it: transcription, scoring, notes, messages, reminders, enrichment, approval and reporting.

The decision table for an SMB

The choice does not depend on ideology about SaaS or open source. It depends on the company's context.

Criterion	Classic SaaS	CRM vibe-coded from scratch	Personalized open-source base
Start	Fast if the need is standard	Very fast for a prototype	Medium, because scoping and deployment matter
Initial cost	Usually readable, sometimes underestimated	Apparently low	A real project to scope
Medium-term cost	Licenses, options, consultants	Unpredictable maintenance	Infrastructure, maintenance, targeted changes
Customization	Strong within the designed frame	Total, but risky	Strong on an existing structure
Security	Mature on the vendor side	Must be built	Must be operated properly
Data	Stored by the vendor	Yours if designed well	Yours with self-hosting
Maintenance	Depends on vendor and admins	Depends on produced code	Depends on the base and your integrator
SMB scalability	Good, but sometimes expensive	Uncertain	Good if the architecture is thought through
AI agents	Increasingly integrated	Anything is possible, so everything must be secured	Agents connected to an existing model

In practice, I would often recommend:

SaaS if the sales process is standard, the team wants little technical responsibility and license budget is not a problem.
A vibe-coded prototype if the company wants to test an idea, validate a workflow or create a non-critical internal tool.
A personalized open-source base if the CRM becomes a business asset, data control matters, workflows are specific and the company accepts serious support.

The last condition matters. A personalized open-source CRM is not a shortcut around expertise. It is a way to invest that expertise better.

What to clarify before building

Before touching the tool, I would ask five questions.

1. What is the real sales process?

Not the ideal pipeline. The real one.

Where do leads come from? Who qualifies them? Where do conversations happen? When is an opportunity created? When is a quote prepared? Who approves a discount? When do you follow up? When is an opportunity lost? Which information must be absolutely reliable?

A poorly scoped personalized CRM will reproduce existing disorder with a better interface.

2. Which data must become reliable?

Not all data has the same value.

In an SMB, I prefer identifying a few critical objects: contacts, companies, opportunities, quotes, calls, messages, tasks, invoices, statuses. Then we decide what must be checked, deduplicated, enriched, historized and synchronized.

The goal is not to have many fields. The goal is to have the right fields, used by the right workflows.

3. Which actions can the AI agent perform?

An agent connected to the CRM can be very useful. It can summarize a call, prepare a note, propose a follow-up, detect a hot opportunity, create a task, prefill a quote or flag an inconsistency.

But it should not do everything alone.

I would apply the same logic as in my article on human approval for production AI agents: the agent can read and prepare many things, but actions that commit the business should go through thresholds, permissions and sometimes human approval.

4. Who operates self-hosting?

Self-hosting is not just "put Docker on a server".

You need to manage:

updates,
backups,
restore procedures,
environment variables,
API keys,
monitoring,
logs,
administrator access,
certificates,
alerts,
rollback plans.

On a stack such as Hetzner, Coolify and n8n, this is absolutely accessible for a well-supported SMB. But it must be treated as a production responsibility.

5. What is the reversibility plan?

The promise of open source and self-hosting only matters if the company can actually get its data out.

Before deploying, I want to know:

how to export contacts,
how to export opportunities,
how to recover history,
how to document custom fields,
how to rebuild the environment,
how to resume the project if I am not there tomorrow.

This is a trust issue. An SMB should not replace SaaS lock-in with provider lock-in.

Where I add value in this model

The topic is not simply "knowing Twenty".

A traditional CRM manager can be excellent at configuring a tool, cleaning pipelines, training sales teams and improving data discipline. That is a real job. But the personalized open-source model also requires other skills.

You need to talk to the founder about sales process, then to the deployment server, then to the CRM through an API, then to the AI agent, then to the team that will use the tool every day.

This is where my positioning adds something different.

I can approach the problem as a complete system:

business scoping with the founder,
choosing between SaaS, open source and specific development,
secure self-hosting when relevant,
connection to n8n workflows,
AI agent integration,
human approval guardrails,
handover documentation,
progressive improvement with AI-assisted code.

OpenClaw and Hermes fit naturally into this logic. An OpenClaw assistant can give teams a more natural work interface over existing tools. A Hermes agent can orchestrate more advanced actions with the right safeguards. But the value is not the agent alone. The value is the system in which it acts: clean data, controlled permissions, traceable actions, clear approvals.

In other words, I do not sell "a vibe-coded CRM". I build an operational base the company can understand, use and evolve.

Mistakes to avoid

The first mistake is choosing open source only to reduce the bill. That is rarely the right angle. Yes, medium-term cost can be lower than a large SaaS in some cases. But only if the architecture is simple, documented and maintained. Otherwise, the bill simply moves from licensing to chaos.

The second mistake is customizing everything too early. An open-source base makes it tempting to change many things. Resist that. I prefer starting with the flows that create real value: lead capture, qualification, opportunity tracking, automatic notes, follow-ups, quotes, reporting.

The third mistake is neglecting adoption. A very well designed CRM that nobody uses is worthless. Sales reps must save time. The founder must see better. Admin must re-enter less. If the tool requires more effort than the old workaround, people will bypass it.

The fourth mistake is letting the AI agent act without a log. Every important action must be traceable: source, decision, data used, result, possible approval. This is essential for trust.

The fifth mistake is confusing ownership with sovereignty. Having the code and the server is not enough. You also need to understand the architecture, document decisions, control access and know how to restore data.

Where to start

For an SMB asking this question today, I would not start with "which CRM should we choose?"

I would start with a short audit:

Map the real sales cycle.
List the tools already used.
Identify the data moving between forms, email, phone, quotes, invoices and support.
Spot duplicates, re-entry and breakpoints.
Classify actions by risk.
Decide what deserves standard SaaS, automation or an open-source base.
Build a first limited scope that can run in production.

The right first project is not "replace all of HubSpot". It is often:

centralize contacts and opportunities,
automate note creation from calls or messages,
prepare follow-ups,
connect the CRM to the quote tool,
deploy an internal assistant that retrieves information,
add human approval before sensitive actions.

Then, and only then, expand.

It is the same logic as workflow automation: do not chase one grand software revolution. Build one reliable loop, measure adoption, correct it, then add another layer.

Sources Consulted

Sources consulted on June 2, 2026:

Conclusion

SaaS is not dead. Vibe coding is not magic. Open source is not operationally free.

But something is truly changing.

For years, an SMB had to choose between rigid standard software and heavy custom development. Coding agents, modern open-source CRMs and automation platforms make a third model possible: start from a solid base, then adapt it precisely to the business.

This model requires more responsibility than ready-made SaaS. It requires scoping, security, self-hosting, backups, permissions, tests, approvals and proper documentation. But in exchange, the company gets something valuable: a tool that is not only rented, but understood.

For a 5 to 50 person company, this is often where the best decision sits: do not build a CRM from scratch, do not accept a rigid machine by default, but create a customizable commercial base connected to real workflows and ready for AI agents.

If you are thinking about leaving a rigid SaaS, structuring your CRM or connecting Twenty, n8n, OpenClaw or Hermes to your sales process, this is exactly the kind of project I handle through AI agents and workflow automation. The objective is not to build a beautiful demo. The objective is to build a system your team can use on Monday morning.