Building Phende: why I built a CRM for developers

Every CRM I've used has the same problem: it's designed for a salesperson clicking through a UI, not a developer who wants to automate everything through code. When I needed a CRM for a product I was building, I spent more time fighting the tool than using it.

Phende started because I was tired of fighting.

The Problem

I needed to track leads, manage conversations, and connect my backend to the CRM. Every tool I tried had webhooks as an afterthought—something bolted on, not central to how the tool was designed. Integrations were brittle. The API was an API for the UI, not for automation.

What I actually wanted was a CRM where the primary interface was code.

The Idea: Code-First

// Your backend stays the source of truth
Phende::createContact([
    'email' => $user->email,
    'name'  => $user->name,
    'tags'  => ['trial', $plan],
]);

Phende::createDeal([
    'contact' => $user->email,
    'value'   => $amount,
    'stage'   => 'new',
]);

The CRM is a view on top of your data. Not the source of truth—your application is. Phende reflects what your code tells it.

Technical Decisions

Laravel for the backend because API-first design is natural in Laravel. Vue for the dashboard that does exist—you still want to see things visually sometimes. Queues for all the async operations. Webhooks as a first-class feature, not an add-on.

The hardest part was deciding what not to build. A code-first CRM doesn't need a workflow builder, a drag-and-drop pipeline, or 40 integration options. It needs a clean API, reliable webhooks, and fast search.

What I Learned

Building a product you actually need is motivating in a way nothing else is. Every feature decision is personal. You feel the friction immediately when something is wrong.

Phende is live at phende.es if you want to see where it ended up.