DEV Community: Douglas D

Your CRM probably has an MCP server now. Here is why I still run my own.

Douglas D — Wed, 05 Aug 2026 16:18:07 +0000

Most of the big CRMs shipped MCP servers this year. Fair question, then: why did I keep building one?

I get asked some version of this every week, so here are the actual answers.

"Your CRM already has an MCP server. What is left to build?"

A CRM MCP server can answer CRM questions. That is the whole ceiling.

The problems that actually cost me money do not live inside one tool. They live in the seams. A task that has gone quiet. A client I have not spoken to in nine days. An open invoice attached to that same client.

Any one of those is unremarkable. You would not act on any of them alone. Together they are a decision I did not know I needed to make, and no single system holds all three, so no single-system MCP server can put them in front of me.

That join is the entire reason Founders OS exists. Not more tools. One read across CRM, ledger, and decision history at the same time.

"So it tells you what to do?"

No, and I am careful about this.

It surfaces the relationship. The invoice and the silence and the stalled task get put next to each other in one answer. What that means is my call. I have no interest in shipping something that pretends to have judgment about my business, and you should be skeptical of anything that claims otherwise.

The useful version is narrower and more honest: show me the thing I would not have looked for.

"Is this just search over my data?"

It reads live records through typed tools and joins them in one pass. Ask about a customer and you get the record, what has been invoiced and paid and is still open, and the interactions and decisions attached to them. One question, one answer, three domains.

The difference matters when the data changes hourly. There is no index to go stale.

"Where does the data live?"

Your own Postgres. It runs over stdio, self-hosted, MIT licensed.

That is a deliberate choice, not a slogan. Business data is the category where I want the storage decision to be mine, and I want no part of the migration conversation if I ever change my mind. Deploy it yourself, point it at your database, done.

"Which AI tools does it work with?"

Anything that speaks MCP. I use it in Claude and in Cursor against the same database, which is the point. The context follows the work, not the app.

"What is it bad at?"

Setup. It is deploy-it-yourself, so there is real work between cloning the repo and getting your first answer. If you want to sign up and be running in ninety seconds, this is not that, and I would rather say so than waste your afternoon.

It is also only as good as what is in it. Empty database, useless answers. Same as every system of record ever built.

If you are building on MCP or just want to poke at the schema:

Repo: https://github.com/OurThinkTank/founders-os Site: https://foundersmcp.com

Happy to answer anything in the comments, especially on the cross-domain query design. That was the hard part.

Before I email a client, I ask my AI where we actually stand

Douglas D — Mon, 27 Jul 2026 12:00:53 +0000

We do fractional CTO work, which means at any given moment we are mid-thread with five or six clients, and every one of them is at a different point. One is waiting on a proposal. One paid last week. One is waiting on an answer to a scope question we never followed up on. The context lives in our heads until it does not, and then we send an email that makes me look like we forgot the last conversation. Because, we did.

So we built the thing we actually needed into Founders OS and this is the one capability we lean on more than all of the flashy ones.

Every time we talk to a client, it gets logged against that customer. Call, email, meeting note, the scope question we said we would circle back on. Nothing fancy, just a running record tied to the person instead of scattered across inboxes and our collective memory.

The part that earns its keep is what happens right before we hit send. We ask one question: what is the last thing we told this client, and where do we stand on everything with them. It reads the interaction history, a vector based memory system, and the financial ledger in the same check. Last contact was eleven days ago on a scope question we never answered. There is an invoice open from the job before this one. Now the email we were about to send writes itself differently, because we were able to get all the context in one question.

That join is the whole point. The interaction log alone is just notes. The ledger alone is just numbers. Together with the memory capabilities they tell us the actual state of the relationship, which is the thing that decides what we say next. No single tab was going to give us that.

If you juggle a book of clients, how do you keep track of where each relationship actually stands before you reach out? Before Founders, we kept it in spreadsheets and folders of documents and notes. Curious whether anyone has found something better than a running log.

GitHub: https://github.com/OurThinkTank/founders-os
Site: https://foundersmcp.com
npm: @ourthinktank/founders-os

Nothing in my task list said "stuck." My AI found it anyway.

Douglas D — Sat, 18 Jul 2026 10:12:00 +0000

I run a small consulting shop. The failure mode is never a dramatic one. It is a thing that quietly stopped moving three weeks ago and nobody noticed because it still looks fine in the task list.

Task lists are bad at this. A task sitting in "in progress" looks identical whether it moved yesterday or in June. The signal that it is actually dead lives somewhere else: the client attached to it has not been contacted in two weeks, the invoice tied to it is still open, and the last note on it was a question nobody answered.

That is three different systems. So I built the thing that reads all three at once.

What the query actually does

Founders OS is an open-source MCP server. When I ask my AI client "what is stuck," it does not grep my tasks for a status flag. It pulls from three domains and joins them:

Tasks: what has an open state and no activity since a threshold date
CRM: when the linked customer was last contacted, and what that interaction said
Ledger: whether money tied to that work is outstanding

The answer comes back as a picture, not a list. Something like: this task has not moved in 11 days, the client on it went quiet after asking about scope, and their invoice from last month is still open.

None of those three facts is alarming alone. Together they mean the engagement is stalling and I need to send an email today.

That is the whole thesis of the project. A single question that reasons across CRM, financials, and memory beats three tools that each answer a fragment perfectly.

Why it is an MCP server and not an app

I did not want another dashboard. I have enough dashboards. I wanted the context to live inside the tool where I already think, which for me is Claude, and for other people is Cursor or something else entirely.

MCP makes that portable. Same server, any client. I move between tools during the week and the business context follows me instead of getting stranded in a tab.

Where the data sits

It runs over stdio against your own Postgres. You deploy it, you own the database, you point it at your own instance.

This was deliberate. I was not going to put my client list, my contact history, and my books into a hosted service I do not control just to make an AI assistant slightly more convenient. If someone else wants to run it against their own infra, the setup is the same for them as it is for me. No lock-in by design, because the design never assumed a middleman.

It is MIT licensed and it is what I actually use to run my business every day.

GitHub: https://github.com/OurThinkTank/founders-os
Site: https://foundersmcp.com
npm: @ourthinktank/founders-os

The question I keep chewing on

Everyone building AI tooling right now is solving retrieval. Fewer people are solving the join. Getting the right document into context is easy compared to getting the right relationship between three records in different systems into context.

If you are building in this space, I would like to hear how you handle it. The joins are where the real work is.

My AI hunts contracts for me: The part that made it start winning business was the retro.

Douglas D — Fri, 10 Jul 2026 11:39:13 +0000

I built a playbook inside Founders OS that hunts for consulting contracts. It searches listings, scores each one against what my two-person shop actually wins, writes tasks for the good ones, and drafts proposals for the exceptional ones. Standard automation so far.

The part that matters is the last step of every run: a retrospective. After I act on a batch, the playbook asks me what the scores got wrong. What did I pass on that scored high? What did I chase that went nowhere? What red flags or stats do the no response bids have in common. Then it writes those lessons back into its own scoring rubric. The next run starts smarter than the last one.

Here is what that loop actually taught it, in order, from real runs.

Run one, it fired a strong proposal at a $25K build with fifty-plus proposals. Never got viewed. Client hired someone else. Same thing happened on the next crowded listing. The retro turned that into a rule: a crowded slate where the client is already deep in their funnel is not competitive, it is dead. Stop spending effort there.

A few runs later it was still docking good clients just for having thin payment history. I told it that was wrong, thin history is fine if payment is verified. It corrected the rubric. But then it learned the sharper version on its own runs: do not look at whether a client has history, look at what they paid past hires. A client whose prior hires were all sub-ten-dollars-an-hour, or whose past jobs were all credit-repair gigs, is a red flag no matter how good the listing reads.

Then it learned to prefer fixed-price over hourly, because that is how we actually want to get paid. It learned that "already interviewing a dozen candidates" beats rate and fit every time, skip it. It even fired two search terms that kept returning the wrong domain entirely.

None of that came from me sitting down to write rules. It came from the system reading its own outcomes and adjusting.

The result is not a flood of wins. It is a much tighter shortlist and far fewer wasted bids, and it has started landing wins on and more proposal engagement as it adapts. For a two-person shop where my time is the whole budget, not chasing the dead listings is the win.

One more thing that mattered to me. All of that learning, every lesson about what converts and what does not, lives in my own database. Founders OS is open source and self-hosted, runs over stdio against my own Postgres. The memory of what works for my business is not sitting in someone else's SaaS that I would lose if I left.

GitHub: https://github.com/OurThinkTank/founders-os
Site: https://foundersmcp.com
npm: @ourthinktank/founders-os

If you run a small shop, how do you decide what work to chase? I am curious whether anyone else has tried to make that decision learn from its own misses.

Why my business AI runs on stdio and my own database, not a SaaS backend

Douglas D — Thu, 02 Jul 2026 09:01:16 +0000

I build for a living, mostly as a fractional CTO, and I got tired of one thing: every time I opened an AI client to help me run my company with a specific client, I had to re-explain the company first. Who the client is. What we invoiced them. When I last talked to them. The AI was smart. It just had no idea what my business actually was.

So we built Founders OS. It is an open-source MCP server that gives your AI client real business context: CRM, financials, tasks, playbooks, guardrails, and a memory layer. You point Claude, Cursor, or any MCP client at it and it can answer across all of that in one shot. Not "here is your CRM data" and separately "here is your ledger." One question, both sources, one answer. Which clients are behind on payment and when did I last contact them. That reads the ledger and the CRM together because they share the same context.

Here is the part I want to talk about, because it was the real decision: it runs over stdio, self-hosted, on your own Postgres DB. No hosted backend in the middle. No account with us. No data leaving your infrastructure unless you decide otherwise.

That was deliberate, and it cost us the easier path.

The easy version is a SaaS backend. You sign up, we hold your data, done. Cleaner install, nicer funnel. But think about what this data is. It is your customer list, your revenue, your unpaid invoices, your private notes on deals, and your knowledge. Data like that should live where you decide it lives, not wherever a vendor's AI feature happens to need it. So we made self-hosted the default and the floor. It is free, open, and yours, and it always will be.

Later we will offer a hosted option for teams that would rather we run the ops than run it themselves. When we do, it keeps the same rule: your data stays in your own database, single tenant, export anytime, no lock-in, and the whole thing stays open source. Convenience is the thing you would be paying for. Ownership is not something you ever hand over.

So the model is: you deploy it, it talks to your own database, and the transport is stdio between your MCP client and the server. Your business context lives where your business already lives. Run it self-hosted and we never see it, and nothing phones home when you close the client.

The tradeoff is real. Self-hosted means you deploy it yourself. There is no magic hosted URL to paste, yet. For a founder or a small team that already runs their own stack, that is a feature, not a chore. You own the whole thing.

It is 100 percent open source and live now. If you run your business through an AI client and you are tired of re-explaining your company every session, this is for you.

Repo: https://github.com/OurThinkTank/founders-os
Site: https://foundersmcp.com
npm: @ourthinktank/founders-os

Built by OurThinkTank. Happy to answer anything in the comments, especially on the self-hosting setup or the memory layer.

I gave my AI client my real business context, and stopped explaining my company and customers every session

Douglas D — Tue, 23 Jun 2026 10:22:55 +0000

Every time Vince and I opened Claude to help with our business, we filled in pertinent data about the business. Who this customer is. What we charged them. What we said last time. The AI was capable. It just had no context, so we provided the context, every time.

Vince and I built Founders OS to help us run our business with AI. It is an open-source MCP server that hands your AI client the actual state of your company: CRM, tasks, projects, a double-entry financial ledger, and a semantic memory that persists across sessions. It runs locally over stdio and stores everything in your own database. No middleman, no SaaS account, and most importantly no data leaving your control.

The part that changed how we work is cross-domain reasoning. We ask one question and the model reads across modules to answer it. "Which customers we closed this quarter still have an unpaid invoice, and what did I promise them last time we talked?" That is the CRM, the ledger, and memory in a single answer. Before, that was three lookups and a spreadsheet. Now it is one sentence.

Because it is self-hosted, the data ownership story is simple: it is your own database. You run the migrations for the tool groups you want, point your client at it, and that is the whole deal. Each teammate runs their own instance against the shared database, and that shared DB is what defines your org boundary. Personal memory stays personal, org memory is shared.

It is MIT licensed and live. If you have ten minutes:

Repo: https://github.com/OurThinkTank/founders-os
npm: @ourthinktank/founders-os
Site and setup: https://foundersmcp.com

If you try it and something is rough, open an issue. We are building this in the open and dogfooding it on our own company every day.