Four months ago I looked at the HubSpot charge on my statement and did something I’d been talking myself out of for two years. I built my own CRM.
I tested it. I ran PerformanceLabs on it for a week. Then I canceled HubSpot and never looked back.
That would be a tidy productivity story if it ended there. It didn’t. That CRM is now Mindmoor, and it runs at three companies. It also no longer just a CRM. It’s become a business operating suite: a newsletter engine, a content operating system, client invoicing and AI meeting capture, all running on the same core. We built each one because someone asked for it.
Here’s the uncomfortable part. For thirty years, the answer to “build or buy” was buy. That answer just flipped, and most leadership teams are still signing three-year renewals like nothing happened.
I paid for this lesson long before I built the fix
I’ve installed more CRMs than almost anyone I know, across executive RevOps roles from enterprise media to scrappy startups. In one of those roles we spent $250,000 and 18 months implementing Salesforce.
Every one ended the same way. We bent the business to fit the software. We trained people to think like the tool. Six months after go-live, the sales team was back in spreadsheets, and the CRM had become a very expensive place to store stale data.
I knew it. I signed the renewals anyway. That’s what you did. Building was slower, riskier and more expensive than putting up with it.
The internal tool didn’t stay internal
Shortly after I canceled HubSpot, we signed our first client. Instead of configuring someone else’s software for them, we gave them their own instance of what I’d built for myself: their own login, their own database, their own API key, their own subdomain. Nothing is shared with anyone.
Two more clients followed.
That’s three clients in four months, on a product that didn’t exist in May.
Here’s what got built along the way:
A CRM that fills itself in. Paste an email, a note or a phone photo of a business card, and the record builds itself, with a confidence score on every field.
A newsletter engine. Our own sending platform. It delivers The AI Operator’s Brief every Friday.
A content operating system. It reads my weekly Substack, and distills it into a week of posts across the channels I use to promote my business.
Client invoicing. More on that in a second.
AI meeting capture. A live transcript turns into structured decisions, next steps and open questions, and no audio is ever stored.
Every client request is now a product meeting
In September, one of our clients told me QuickBooks invoicing stressed her out. She asked whether invoicing could go on the roadmap.
It never went on a roadmap. We scoped it that week and built it the next. It uses her payment terms, her deposit rules, invoice numbering, brand template, and her product catalogue. QuickBooks stays the ledger, with a clean monthly export for her bookkeeper. Every payment reminder waits for her approval instead of going out on its own. Now any client can turn it on.
That wasn’t a one-off. After a single call in August, she surfaced a number of feature requests. Three days later we shipped the first slice. When she mentioned she was typing business cards by hand, we shipped a capture straight from her iPhone camera.
Think about how this used to work. You submitted a ticket to a feature request portal. It got upvoted, or it didn’t. You paid $3,000 to fly to the annual conference and sat through the keynote hoping your one feature made the slide. If it shipped at all, it shipped a year later, built for the average customer. In other words, built for nobody.
Now you tell a partner what you need. We validate it and build it, and it ships to you. If it’s good for everyone, it ships to everyone.
That only works because of how the system is built. Every client runs in a fully isolated environment, with its own database, API keys and authentication. Features deploy client by client, so two companies can run the same core with completely different modules. Standing up a new client instance takes us a few days.
We’re not the only ones seeing this. McKinsey’s State of AI survey, published last month, found that 32% of organizations passed on a software purchase because they could build it themselves with coding agents. Retool found that 35% of the builders it surveyed had already replaced at least one SaaS tool, and 78% expect to build more this year.
A third of the market has already walked away from a purchase. The vendors will be the last to notice.
Building is cheap now. Running it is where the bodies are buried.
This is the part that the “I built an app over the weekend” crowd skips.
In August I found a local LLM project I’d built in May. It burned through 5 million tokens and I hadn’t touched it for two months. Nothing flagged it. I only found it because I happened to check. When you’re $1K per month deep in monthly AI tool subs, it’s easier than you’d think.
That’s the real divide. Anyone can generate code now. Far fewer people build with security and architecture first, with audit trails, and with the checks that catch what the code gets wrong. It’s why I wrote that you should never fire the person who checks the work.
It’s also why we’re building Sanction. A tool that authorizes AI spend to protect against agents going rogue and burning tokens.
According to IDC, only 1 in 5 CEOs has set up a separate AI budget line. Most companies can’t tell you which agent is spending what, let alone stop it. Sanction sits between every agent and everything it can touch. Before an agent spends money, calls a tool, touches a credential or spins up a resource, it has to ask. Sanction approves the request, escalates it to a human or denies it. It runs one policy engine across every model provider, with a signed audit trail behind every decision.
Speed without governance isn’t innovation. It’s a bill you haven’t opened yet.
Soon the roadmap will come from the people doing the work
This next part is what I think most companies have no idea is coming.
Today, a client asks me for a feature. Soon they’ll ask the platform. An agent will scope the request, check whether we’ve already built it for someone else, and draft the build. A non-technical admin inside the client’s company will approve it against how their business actually runs. Think of a Salesforce admin who never has to learn to code. Then it ships to their instance.
Every approved request feeds a shared library. The system gets smarter with every client, and every client benefits.
At that point, the product roadmap stops being a slide at a conference. It becomes a feedback loop. It starts with someone on the front line saying what would make their job easier, and it ends with software that fits.
That isn’t a better SaaS company. It’s a different category.
The Takeaway
Some people will read this and say, “I’m not trusting software whose first line of code was written four months ago.”
Fair. But you’re already trusting a vendor who hasn’t shipped what you asked for in four years.
I understand why this feels wrong. When work shows up faster than you expect, the speed reads as risk instead of value. We’re all calibrated to a world where good software took eighteen months and a quarter of a million dollars. If you’ve spent the last twenty years in the executive chair, this should make you uncomfortable. It feels weird to me, and I’m the one building it.
The discomfort isn’t a signal to slow down. It shows how far behind the old model already is.
So stop asking whether you can trust software this new. Start asking why you’re still waiting on software this old.