This tutorial was written by Néstor Daza.
I use Claude every day. It's a great tool for my day-to-day work, helping with everything from research and text processing to, above all, writing code (nothing surprising here). But today, that little coder voice in my head asked me: what would it take to build my own version, running on infrastructure I understand and control? What if I could have my own AI bot? So that is what I am doing, and this is the first entry in a series documenting it.
The app is called Claudius. It is a personal, Claude-style chat workspace I am building for myself, with MongoDB as its entire backbone and Claude models served through AWS Bedrock. Every article in the series will ship with public code. The app runs on MongoDB Atlas’s free tier, so nothing here is a pattern you read about and cannot reach. You can clone it, run it, and lift the parts you want into your own work.
Why build it when Claude already exists?
Yes, yes, Claude already exists, and it is very good, so why build a smaller, less-featured version of it? Because the best teacher is you, building with your own hands! Building the agent loop by writing the code, with state and retrieval, I actually have to figure out how to make it work, and the entire infrastructure needed to run it will not only show me a lot of what a finished product hides, but should also be a really fun project!
There is a personal payoff, too. I want a chat app where I own the data, one that remembers the things I tell it across conversations, sitting in a database I run. It is built for me first, and keeping it personal also keeps the scope honest.
The build is also great content. Writing is part of what I do, so a project I would build anyway turns into a series that other developers can follow. That's the reason you are reading this.
MongoDB is the whole backbone
Having MongoDB as the only datastore in the project is the decision that shapes everything else. Not a database plus a cache plus a vector store plus a queue, just MongoDB.
That is uncommon enough to need some explaining. A chat app like this has to keep users and conversations somewhere. It has to persist the agent's working state so a conversation survives a page reload. Retrieval over your documents and long-term memories needs a vector store. Background work, once it shows up, needs somewhere to queue. The usual answer is to use a separate product for each of those, and you end up operating four systems that have to be kept in sync. I am using MongoDB throughout, because the document model and Atlas Vector Search cover that whole surface, and one database is far less to run and reason about.
Embeddings come from Voyage AI, which is now part of MongoDB. That matters more than it first sounds. The data and the retrieval layer that sits on top of it come from the same place, so there is no second vendor to manage for the part of the app that handles search. Voyage's models are also strongly multilingual, which I care about because I work across AMER and LATAM in English and Spanish, and embedding quality in Spanish is the difference between retrieval that works and retrieval that only pretends to while quietly missing the point.
If you come from a relational background, I will translate and mention parallels and differences as we go. When a document-model choice replaces something you would have built with a join table or an extra service, I will say so, explain it, and show the relational equivalent to make the tradeoff clear.
Why is Claude running through Bedrock?
The one big piece that is not MongoDB is the model layer, and every Claude model the app uses is served through AWS Bedrock. This choice comes down to convenience and ease of use: being able to move from a fast, cheap model to a slower, more capable one is a single string in a request, which makes the model picker in the UI almost free to build. Keeping model access within a single cloud relationship also puts credentials and billing in one place, which matters the moment there is a usage bill to watch.
What it does, and what it isn't
So what does Claudius actually do? Four things only. I'm capping the scope of the whole project right here.
It holds a streamed conversation and lets me switch Claude models in the middle of a thread. It remembers, both within and across conversations, persistent facts instead of hoarding transcripts. It lets me upload a file and ask questions answered from its contents. And it can run a longer research task that plans an approach and works through web sources to return a cited answer.
But it is not a product! There is no commercial plan behind it, no growth target to hit, and more importantly, I'll leave the full-blown version of a Claude Agent to the good folks at Anthropic; my plan is to keep Claudius very slim. Sign-in is Google and nothing else, and a user's role is decided on the server, so no public path hands out anything on its own. It is built for me, and late in this series, I open a small public tier so readers can try the finished thing. That tier is hard-capped but open enough to show you what the end result looks like, so stay tuned for one of the final articles of this series!
This is not a clone!
One very important thing to be clear about: Claudius is a personal homage and a learning project. It is not affiliated with or endorsed by Anthropic, and it is not meant to replace Claude, which remains the real thing. This is me rebuilding the shape of a tool I use and admire, to understand how it stands up, while showcasing the power of MongoDB as the sole data foundation of a complete agentic AI application.
How it will be built
The build runs in six phases, and the article series will track them closely.
Phase 0 lays the foundations, the data model, and the auth/role system that everything else assumes. Phase 1 brings the streaming chat backbone, Claude over Bedrock wired into the frontend, the first real conversation. Phase 2 adds file upload and retrieval for what you upload. Phase 3 is the one I am most looking forward to: long-term memory that survives across conversations. Phase 4 moves the heavier work, including the research agent, onto a background worker. Phase 5 closes the loop with usage metering and cost controls, and opens the small public tier.
Because every phase ships with public code, hosted in Github. The repo carries an annotated .env.example that lists every credential the build needs and the phase it belongs to, so you can reproduce each step instead of just reading it.
When the public tier goes live near the end of the series, it will live at askclaudius.dev, and you will be able to open the finished app and use it yourself.
That's enough on the why. The next article comes with the decision that surprised me most: Claudius has no message table! I'll show you where the conversation really lives, and why the document model is the right call and not just a clever hack. If you came up on SQL, this is the one to read!
Top comments (0)