I built an AI-native CRM from scratch. Here's what actually happened.

A lot of what I do is experiment. I build AI systems for clients, but I also just build things — to understand what's possible, to stress-test ideas, and to have something real to point to when I'm telling someone what AI can actually do in production.

CARM started as one of those experiments. It became something I'm genuinely proud of.

The problem I wanted to solve

A client I was working with — a Melbourne management consultancy — was using a standard CRM. It worked fine. But the more I looked at it, the more I saw a fundamental mismatch between what the tool was and what the business actually needed.

Every relationship, every deal, every conversation was being faithfully logged — and then just sitting there. The CRM stored data. It didn't think about it. All the pattern recognition, the "this deal looks like it's stalling," the "we haven't spoken to this contact in six months" — that was all still happening in someone's head.

I also kept coming back to a sovereignty question. Client names, deal values, strategic conversations — all of it on third-party servers in jurisdictions nobody had really thought about. For a firm handling sensitive commercial work, that felt like an unexamined risk.

So I decided to build something different and see how far I could take it.

What I built and how

CARM runs on Supabase in Sydney, with an AI layer on AWS Bedrock in ap-southeast-2. Every byte stays in Australia. The front end is Lovable — React under the hood — wired to a set of AWS Lambda functions. Claude Sonnet handles the heavy reasoning. Haiku handles the fast utility tasks like query translation and summarisation.

The features I'm most interested in aren't the core CRM stuff — that's table stakes. It's what happens when you put AI properly inside the system:

Natural language search. You type "deals over $400k in financial services with no activity in 30 days" and it runs the query. You say NAB and it knows you mean National Australia Bank. No filter builder, no dropdown hell.

A relationship map that answers questions. "Who do we know at ANZ and how are they connected to our Westpac contacts?" — visual answer, instantly. The kind of thing that used to take someone ten minutes of cross-referencing.

Meeting reports from transcripts. Drop in a Fathom or Fireflies transcript, get back a structured report — decisions, actions, relationship notes — logged against the deal automatically.

A Proposal Agent on every deal. Open a chat panel, have a conversation, and it generates a PowerPoint or PDF proposal drawing on everything it knows about that deal. Company, contacts, stage, activity history, research brief. The output saves directly to the deal's file section.

Client research briefs in 20 seconds. Hit a button on any company record and it pulls recent news, key people, financial context and strategic priorities from the web. Useful before any client meeting.

A CRM assistant in the corner. Ask it anything. "Who's our contact at Telstra?" "What are our must-win deals this month?" "Tell me about the Westpac opportunity." It queries the database, respects permissions, and answers in plain English.

What building it taught me

The AI parts weren't the hard parts. The hard parts were schema design, permissions, and getting the data model right so that everything — especially the AI features — behaved correctly at the edges.

Take permissions as an example. CARM has multiple user types — internal staff who see everything, and external partners who only see deals and companies within their permitted sectors. Getting that right isn't just a security requirement, it's a trust requirement. If a partner user runs an AI query and gets back data they shouldn't see, you've got a problem that no feature list makes up for. Row-level security in Supabase handles this cleanly, but only if you design around it from the start. Bolt it on later and you're in trouble.

The same was true for the AI layer. Every query the assistant runs, every summary it generates, every research brief it pulls — all of it had to respect the same permission model. That meant thinking carefully about how data was fetched and passed to the model, rather than just dumping everything into a context window and hoping for the best.

The other thing that struck me: how much you can build by composing existing infrastructure rather than building from scratch. Supabase handled auth, the database, storage and edge functions. AWS handled the AI layer. Lovable handled the front end. I designed the system and wired the pieces together. The total cost is a fraction of what an off-the-shelf enterprise CRM would run annually.

And the features that get used most aren't the impressive ones. It's the natural language search. It's the summary on a deal record. It's the assistant answering a simple question in two seconds. The mundane problems, solved properly — that's where the value is.

What's still being built

CARM isn't finished. It probably never will be, which is part of what makes it useful as an experiment.

On the near-term list: a client portal where external stakeholders can log in and see deal progress relevant to them. Automated follow-up sequences that trigger when a deal sits too long in a stage without activity. Calendar integration so meetings sync to deals without anyone having to manually log them. Email sent directly from within the platform, via AWS SES, so communication stays in the system.

Further out: offline mode for consultants in meetings without reliable connectivity. Contract and SOW tracking against deals. A meeting agenda generator that pulls everything relevant about a client — recent activity, open tasks, relationship notes, research brief — and structures it into a pre-meeting document before you walk in the door.

Each of these follows the same principle as everything else in CARM: don't add a feature because it looks good on a list. Add it when the absence of it is creating friction for the people actually using the system.

Why I'm writing about it

Partly because I think the experiment worked, and experiments that work are worth documenting.

But also because CARM is a good example of what I try to show clients: that AI isn't a feature you bolt onto existing software. It's a different way of thinking about what software should do. Systems that don't just store your work — they help you do it.

There's a version of this for almost every business that runs on relationships, deals, or accumulated knowledge. The stack doesn't have to look like CARM. But the question is worth asking: what would your software look like if it was designed to think, not just to store?

If that's a question you're sitting with, let's talk.