I started with a romantic idea: build the entire product in Rust, with Rust‑first tools, end to end.
I still like that idea philosophically. In practice, it was too much for one person and too far removed from the real goal.

The real goal was simple and already described in Part 0: a fast, practical, keyboard‑friendly app that is online and privacy‑respecting. Not a technology demo. Not a purity contest.
At first, I treated the tech stack as if the technology choices were the product.

For the backend, I settled on combo Rust with Tokio and Axum. I genuinely love FastAPI — it’s the framework I trust the most — but early in the project I wanted to keep operational costs low. Python frameworks tend to have a higher memory footprint, which isn’t ideal for a small, long‑running SaaS.
On the desktop side, I chose Tauri. It allowed me to reuse the web frontend while keeping the application lightweight, secure, and fast. Rust on the backend and Tauri on the desktop ended up being a natural pairing.
This was my final compromise — the last remaining piece of the original Rust‑first dream. Enough Rust to matter, without turning the project into an experiment.

I tried RustFS as object storage. Under load, it quickly became clear that it wasn’t stable enough for my needs. Around the 200‑concurrent‑user mark, things started to fall apart. The project is still in alpha, so that’s no surprise. Maybe it’s a better fit for a future project.

I spent a lot of time trying to make SurrealDB work smoothly in this setup, but I never reached a level of confidence that matched my timeline. Maybe it was the documentation, maybe a skill issue.
MongoDB — a personal favorite — turned out not to be the right fit either, mostly due to its memory footprint. Stoolap was explored and used in early phases, but maintaining multiple database experiments during an early‑stage product simply didn’t make sense.

For the frontend, I experimented with Rust web UI approaches and Rust‑adjacent options. The biggest issue I ran into was the lack of a proper mind‑mapping canvas component. This canvas is the heart of the UI, and I didn’t feel confident enough to start developing something that complex from scratch.

So I changed my approach:

• MinIO for object storage — boring, but reliable
• Rust for the backend — the last practical remnant of my original Rust‑only dream
• PostgreSQL as the current backend storage baseline — a boring, proven, and hard to get wrong
• React + TypeScript for the frontend — chosen for iteration speed and mature tooling, with no need to reinvent anything
• Tauri for desktop apps — lightweight, secure, and a natural fit with Rust

At the beginning, my decisions were more ideological. Over time, I became pragmatic. I like things that get done, and there are always options to choose from.

I wanted an offline‑first feeling, with encrypted persistence to the database and S3‑compatible storage. I wanted the app to feel objectively responsive and immediate. If a thought appears, I should be able to capture it in a fraction of a second — not after waiting for framework ceremonies.

The key lesson of this chapter is simple: constraints come before tools.

When your constraints are clear, technology becomes a means. When your constraints are blurry, technology becomes a trap. I lost time learning this lesson. I don’t regret the learning, but I wouldn’t repeat the same order again.

MindMapVault exists because I finally prioritized the goal over the stack fantasy.