DEV Community: Douglas D

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.