How I Built Eight MCP Servers and a Hotel AI in One Month, With No Programming Background

I am 39. I do not have a computer science degree. Until recently I spent over eleven years working in Norwegian kindergartens and primary schools. My laptop is a HP ProBook that I would not call new. I live in Norway.

In roughly one month of focused building with Claude Code, I went from a clean Linux install to a workspace running eight custom MCP servers, a hotel AI with real integrations, a Python learning platform, a research swarm, a trading research lab, and a small Linux distribution I call VibeOS.

This is not a post saying that is impressive. It is a post about what actually happened, what broke, and what I think is replicable for other people who would like to build real software without the usual credentials.

The stack

For anyone who wants the short version:

• Claude Code is my main interface. Opus 4.6 when it matters, Sonnet for routine work.
• FastMCP (Python 3.11) for every MCP server.
• Qdrant for vector search, two instances, around 100 000 chunks across eleven collections.
• Neo4j for story graphs and entity relationships.
• Mem0 for cross-session agent memory.
• Ollama locally for fallback, Groq (Llama 3.3 70B and 3.1 8B Instant) for speed.
• Caddy in front, Docker Compose for the heavy services, systemd for daemons.
• Hetzner CX43 VPS for the live projects, around EUR 13 per month.

The workspace is a single directory called MWM-AI with seven sub-projects, each its own git repository. One CLAUDE.md at the root routes tools by domain so the trading tools do not wander into the novel project and vice versa.

What got built

Eight MCP servers, each with one clear job:

1. vector-brain. Knowledge retrieval across books, transcripts, research, and code. Fifteen tools, eleven Qdrant collections.
2. mem0-memory. Session memory with Qdrant, Neo4j, and Ollama behind it. Seven tools.
3. youtube-transcript. Transcript fetch and search.
4. pine-architect. Pine Script V6 validation, generation, and strategy management for trading.
5. strategy-lab. 25 tools for backtesting, Monte Carlo, walk-forward, regime analysis.
6. data-engineer. CSV ingestion, cleaning, SQLite storage, querying.
7. topstepx-readonly. Read-only connector to a prop-trading account for monitoring.
8. market-news. News scraping, live quotes, sentiment, pre-market intelligence.

On top of those, four end-user products:

• Belliq, an AI back-of-house for small, receptionless hotels. Guest messages in, automatic answers when safe, handoff to a human when not. Live in a Mews demo environment, waiting on the first pilot hotel.
• PyLearn at pytor.mwmai.no. A Python learning platform running entirely client-side via Pyodide, 400 exercises, and its own tutor agent.
• A research swarm that runs every other morning. Nine scouts fetch from arXiv, PubMed, Hacker News, Reddit, and several newsletters, check each finding against what is already in my Qdrant collections, and drop a short briefing into my Obsidian vault.
• VibeOS, a small Ubuntu + KDE Plasma distribution with Claude Code and my AI tools pre-installed. Built with mkosi. The point is a gentle on-ramp to Linux for non-technical people. The installer still has bugs as of writing, so this one is not shipped in the full sense yet.

How I actually worked

I did not type most of the code. Claude Code did. What I did was design, decide, and read.

On a typical build day the loop looks like this: I describe the thing I want to exist, in ordinary language, the way a teacher would explain a project to a curious student. Claude Code asks clarifying questions, writes a small first version, runs it, fails, reads the error, proposes a fix. I watch. When I see a pattern I do not like, I stop it and ask why.

That last part is the real skill. It is not different from what I used to do as a pedagog. A three-year-old is also an unfamiliar system that occasionally does something surprising. You ask open questions, you watch, you adjust. The Motivational Interviewing training I took in 2021 turns out to be unreasonably useful when you are trying to get a large language model to tell you what it is actually about to do.

The HP ProBook is fine for this. Local inference is slow, so I use Groq for speed and Ollama locally when I do not want the cloud to see something. The rest of the work is reading text and editing files. You do not need the latest hardware. You need a little more patience when something compiles, and good habits about what you close when you are not using it.

Memory is the feature that unlocked everything

For the first two weeks, each Claude Code session started cold. I would re-explain the same things, re-paste the same constraints, lose context when the window filled up. I stopped getting work done and started getting anxious.

Then I built the memory layer, which is really two things sitting next to each other:

• Qdrant stores everything I have read or written that is worth keeping. Books, papers, transcripts, my own notes, every prior session summary.
• Mem0 stores the small, structured facts that decide how the next session should begin. User preferences. Open decisions. What failed last time.

Now every session starts by reading a short index, pulling in whatever is relevant, and resuming work. A drift guard runs twice a day and catches inconsistencies between memory stores before they spread.

This is the thing that changed the rate at which I could build. Not a smarter model. Not a faster laptop. A memory system that stops me from explaining myself twice.

The most recent layer on top of this runs once a week and reads back its own track record. It scores which of its past suggestions I accepted, reverted, or modified, and adjusts its confidence in each rule accordingly. I read the Sunday briefing with my coffee. It is the first thing I have built that can be wrong about itself and know it.

What broke

I do not want to pretend this was smooth, because that would be dishonest and it would also be useless to anyone reading this who is about to try.

• I overwrote my settings.json once without a backup and lost two hours. That is why the PostToolUse hook now backs up configs automatically.
• My research swarm’s synthesis model hit Groq’s 100 000 tokens-per-day cap on the first real run. Silent 429s. I now retry with retry-after, and the scout uses the 8B model with the 500K daily cap instead of the 70B.
• I shipped public repos with personal identifiers in commit messages. Twice. The second time I wrote a pre-push hook that refuses to push if certain strings appear in the diff.
• I optimised a Pine Script strategy to a 4.8 Sharpe ratio in-sample. Out-of-sample, it was a coin flip. Walk-forward with a proper holdout fixed that. Lesson: if the backtest looks too good, it probably is.
• I built Belliq’s first version directly against the Mews production API. Nothing bad happened, but nothing bad happening is not the same thing as safe. I now have a shadow-mode switch and I use it.
• My first attempt at VibeOS died after eight rounds of patching where each fix broke something upstream. I threw the approach out and rewrote it from scratch around a different build tool. The second version boots and runs, but the installer still has two bugs I am hunting. Lesson: if you are patching the same thing eight times, the thing is wrong, not the patches.

Every one of these is in my memory system now. The system itself gets a little better each time I break it.

What is actually replicable

If you have no programming background and you want to do something like this, here is what I think actually carries:

1. Pick tools that have memory. A coding assistant that forgets between sessions is a coding assistant you will fight. Either use one with built-in context, or build the memory layer yourself. This matters more than model choice.
2. Write one CLAUDE.md and keep it short. Name the tools, name the rules, name the things you never want touched. If you cannot fit it in one screen, the project is too big for one workspace.
3. Start every project with a drift guard. Back up before you edit. Log every change. Make errors loud. This is not premature optimisation, this is the thing that lets you work at night when you are tired and your judgment is bad.
4. Ship one real thing before you build the second. Belliq taught me more than all my reading did. A pilot that exists, even if it is waiting on one customer, is worth ten plans.
5. Be honest about what you do not know. If you let the model pretend, you will end up with code that looks like code but does not solve anything. Asking “what are you uncertain about here” is the most productive prompt I know.

Why I wrote this

Partly because I think more people like me should know that this is possible now. Not everyone who wants to build software had the option to study it at 19. Some of us were pedagogs, or nurses, or welders, and we are looking at this new thing wondering if we are allowed.

You are allowed.

Partly because I do consulting now. If you run a business and you want an MCP server built, a Claude Code workspace set up properly, or an agent memory system designed that will not eat itself in three months, I can help. Details at mwmai.no/consulting.

And partly because I wanted to put a flag in the ground and say: this is what one month looked like. Whatever I build next, I want to be able to come back and read this and remember that it did start from here, on an old laptop, with a patient model and a lot of reading.