Engineering
3 min read
thucde.dev changed more than it looks
thucde.dev isn’t just more polished: it has a cleaner frontend, stronger editor, better security, and a more reliable deploy flow.
If you only glance at the homepage or a couple of dashboard screens, the easy reaction is probably: “Looks like some nice UI polish.”
A quick honesty note
This post was drafted with AI help. The work is real, the writing is just more polished than my usual English.
The frontend finally feels like one systemThe frontend finally feels like one system
The frontend finally feels like one systemThe frontend finally feels like one system
One of the biggest shifts is that the frontend no longer feels like a codebase living between two eras.
Over just a few days,
Over just a few days,
thucde.dev- upgrading to Next.js 15
- making shadcn/ui a clearer design foundation
- reducing more of the lingering MUI-heavy surfaces
- finishing the frontend migration to strict TypeScript
- moving more server-owned state away from Redux and into SWR, where it belongs
Thucde.dev
656 x 264, 16.1 KB, PNG
On paper, that can sound like a pile of technical debt work. But that is also exactly why it matters.
Small products often get stuck in a half-old, half-new state for a long time: newer components on top, older state assumptions underneath; App Router in place, but still a client-heavy mental model; TypeScript installed, but not strict enough to catch the bugs that matter early. The result is that every change carries extra fear.
What changed here is not just the UI layer. It is the combination of three deeper improvements happening together:
- 1. rendering model
- 2. state ownership
- 3. type safety
Most readers will not notice that directly, and that is fine. Maintainers will. This is the kind of change that makes the next feature cheaper, safer, and faster to ship.
Thucde.dev
2334 x 1496, 278.9 KB, PNG
The editor now feels more like a real publishing toolThe editor now feels more like a real publishing tool
The editor now feels more like a real publishing toolThe editor now feels more like a real publishing tool
If I had to pick the most visible improvement to show off, it would probably be the authoring experience.
The editor got a serious amount of attention in this "sprint":
- a clearer EditorJS block rendering and registry setup
- better support for richer embeds like Twitter/X, TikTok, and Spotify
- a custom Unsplash picker replacing an older dependency path
- better image metadata handling
- more useful autosave behavior
- better loading and feedback states while authoring
- more polish across blocks like alerts, code, and embeds
Thucde.dev
1040 x 464, 31.1 KB, PNG
Thucde.dev
1366 x 924, 2.2 MB, PNG
And the image is automatically added with a proper attribution!
With the Embed plugin, Thuc can drop in posts and media from most major social platforms with almost no friction.
And more..!
What I like about this set of changes is that it does not only answer “what can the editor do now?”
It also answers the more important question: “is writing and publishing more trustworthy now?”
For a site like
thucde.devSecurity stopped feeling like “something to clean up later”Security stopped feeling like “something to clean up later”
Security stopped feeling like “something to clean up later”Security stopped feeling like “something to clean up later”
Another part of this sprint that feels especially worth mentioning, even if it is not flashy, is the security work.
Across both the backend and frontend, there were a number of meaningful improvements:
- adding Zod-based validation to more mutation endpoints
- adding SSRF protection
- fixing private blog metadata leaks
- gating routes with operational or admin-level impact
- sanitizing HTML in higher-risk blocks like alerts and code
- hardening the Unsplash route with session checks and URL validation
Why does this matter so much?
Because on a content platform, the dangerous edges often hide in exactly the places that feel the most convenient: rendering HTML, accepting external URLs, exposing metadata for private content, or leaving behind a few helpful local/dev routes.
Problems like that do not always explode immediately. More often, they slowly turn into the kind of platform you stop trusting to extend confidently. So in this case, security is not just hygiene. It is part of what makes future progress possible.
Reliability and performance were treated like product workReliability and performance were treated like product work
Reliability and performance were treated like product workReliability and performance were treated like product work
For example:
- reducing an N+1 pattern in homepage hydration
- narrowing build-time static generation to avoid Vercel timeouts
- fixing feed, sitemap, cache behavior, and RSS details so publishing surfaces are more stable
- adding a workspace-level verify script for cross-stack changes
- improving indexes and a few heavier query paths
None of that makes for a dramatic screenshot. But if you are the person running the site, this is exactly the layer that turns a system from “it works” into “it holds up.”
When builds stop trying to do too much at once, deploys get less fragile.
Thucde.dev
2656 x 1694, 1.4 MB, PNG
thucde.dev
Thanks for reading!
