Case study
A self-hosted CRM that fills itself in
maxa-scale is the tool I ended up writing for my own sales activity. It stands here as a demonstration: the name is mine, the mechanics transfer.
0
forms to fill in
The starting problem
I moved from a school-grade spreadsheet to a real tool, and not out of a taste for bespoke software. I simply was not tracking anything. Between a call ending and opening a file to put the right information in the right place, there are a dozen fields, and by the evening you skip it.
Two weeks later, nobody knows who was supposed to chase whom. That is not a tooling problem, it is a friction problem: as long as data entry is manual, it comes after everything else. Most CRMs on the market solve how data is displayed, not how it gets in.
What was built
The application asks for nothing. It is connected to the mailbox; for a LinkedIn conversation, you paste the raw thread; on the move, a dictated note is enough. A model extracts the contact, what was said, and the follow-up to schedule. No form to fill, no re-typing.
Every morning the tool opens on what needs doing: follow-ups due today, exchanges left unanswered, opportunities going stale. The pipeline updates accordingly, with no intervention.
The demonstration
The technical choices, and why
Three structural decisions I carry over to most projects of this kind.
Self-hosting
The application runs on your own server. A customer file has no business sitting with a vendor who can change its terms overnight, and the confidentiality question stops being the same question once the data never leaves.
MCP server secured with OAuth 2.1
The CRM is driven in conversation: "add this lead and remind me in 10 days" is enough. The connector is built into the application and authenticated, so no public API has to be exposed to make that possible.
Your choice of language model
Processing goes through existing subscriptions and can switch to a local model via Ollama: either because the matter is sensitive and no call should leave the network, or simply as a fallback when subscription credit runs out.
What it changes in practice
The question is no longer "is my record up to date" but "what do I do today". With data entry gone, the tracking finally exists, which was never the case with a spreadsheet.
On confidentiality, a local install with a local model runs without a single outbound call. That is verifiable, not a claim.
The same mechanics, for your case
The name is mine, the mechanics are not. Paste raw material, let a model turn it into usable data, and make the whole thing drivable in conversation: that works for a CRM and for plenty of other things.
What I deliver is the application shaped for your case, the hosting, and the source code. If your teams re-type the same information somewhere every week, that is probably where to start.
- Case or inbound request tracking
- Document base queried in plain language
- Back-office tool the market does not cover
- Attachment processing and filing
Frequently asked questions
- No. It is the tool I use for my own business, shown here to demonstrate what is achievable. What I deliver is an application built for your use case, with its hosting and its source code.
- The application is installed on a server you control, on your premises or at the host of your choice. Your data does not pass through a third-party platform, and you do not depend on a vendor to keep accessing it.
- Not necessarily. The model is a setting: depending on how sensitive the processing is, you use a cloud model or one running on your own machine through Ollama. In that second mode, no call leaves your infrastructure.
- MCP is the protocol that lets an assistant such as Claude drive an application. In practice you ask in conversation to add a contact or schedule a follow-up, and it happens in the tool. The connector is secured with OAuth 2.1, so no public API is exposed.
- Yes. The terms covering code, documentation and hosting handover are spelled out in the proposal, before any commitment.