The cutty.dev tech stack — conscious choices
What is under the hood of cutty.dev and why. No evangelism—philosophy: a boring, stable stack, EU-based hosting, and privacy built into an architecture that one person can maintain.
Most "my tech stack" articles are a proud list of trends. This one is about something else — the philosophy behind cutty.dev's choices: boring and stable instead of trendy, European instead of American, private by design, and simple enough for one person to maintain.
Framework: Astro (server-side rendering)
cutty.dev is an Astro application rendered server-side. Every request goes through the server, dynamically assembles the page, and responds with ready-made HTML.
Why: I wanted server-side rendering without heavy machinery, good support for many languages built into the framework itself, and speed without overhead. Astro delivers all of that, and the code remains readable—which in a solo project is worth more than any trendy add-on.
Database: SQLite
One database, one file. Plus a TypeScript-friendly query layer that ensures structural changes immediately reveal errors in the code rather than in production.
Why: cutty.dev is primarily "read-heavy" — every link click involves a read operation plus an increment of the counter. SQLite handles this excellently, even under very high daily traffic. A backup is simply copying one file — no replication ceremony, no complex scripts. Simplicity here isn't about cutting corners on quality; it's a conscious decision that fewer moving parts mean fewer things that can break.
Hosting: server in the European Union
- Dedicated server in the EU
- Custom TLS certificate
- Reverse proxy with automatic HTTPS
- Containerized application
Why: this is the foundation of how cutty.dev handles data. Full control over their location (crucial for EU clients and GDPR), no dependency on a single provider, no automatic replication to the US that large cloud platforms provide, and predictable costs instead of traffic-dependent billing. Convenient Western platforms would offer a faster start — but at the cost of where your users' data physically ends up.
Translations: local AI model
cutty.dev speaks 25 languages, and translations are performed by a local, open-source AI model running on our own infrastructure.
Why: no text from the interface leaves our system — we do not send it to any external AI provider. This results in zero cost per translation and full control over quality: we can refresh translations whenever we want. Machine translation always requires human review — and every language has undergone such a review — but doing it in-house means that privacy is not an option on the pricing list, but a property of the architecture.
CSS: utility-first (Tailwind)
One style system, no CSS-in-JS, no separate style files. Everything directly in the templates.
Why: iteration speed. I don't waste time coming up with class names, and unused styles never make it to the final page. Consistent design enforced by the system itself. For one person, every minute not spent on side tasks counts.
Implementation: containers
Containerized application (Docker), deployed in a repeatable and portable manner.
Why: the same environment locally and in production, no "it works on my machine," and the ability to migrate everything to another server within half an hour if needed. Portability is a form of independence.
What this taught me
- The boring stack wins. Astro, SQLite, Tailwind, containers — everything is mature, well-documented, and stable. Nothing breaks at the most unexpected moment.
- EU hosting is production-ready. The myth "you have to go to a big American cloud to be taken seriously" is just that — a myth.
- Local AI is real. You don't need to hand over your data to an external API to get good translations.
- One person can ship something that looks like a team product. Time is a more expensive resource than money, so every choice here was made to protect time.
See live. Questions about the technical approach — hello@cutty.dev, I respond the same day.