DEV Community: Mohd Salahudeen

Write Once, Post Everywhere

Mohd Salahudeen — Tue, 29 Sep 2026 12:56:30 +0000

Most developer writing gets read on someone else's website. DEV, Hashnode, Medium, a Bluesky post, a Hacker News thread. That's where the readers are, and your own site is often the last place they land.

I'm fine with that. What I'm not fine with is each of those copies competing with the original in search, because the canonical link was never set, was set slightly wrong, or was set once and never checked again.

So I built castio. I publish on my own site the way I always have, push to git, and castio takes it from there. It waits until the post is actually live and shows me exactly what each platform will get. It posts where it can, hands me a ready-made kit where it can't, and then keeps checking that every copy still points home. The original is yours, and every copy should say so. That should hold every day after you post it, not just on the day itself.

Cross-posting is easy. Cross-posting correctly is tedious.

The fix for duplicate content is old and boring: a canonical link. A copy that says "the original lives over there" stops competing with the original. The problem is that every platform handles it differently:

DEV has a canonical URL field on each article.
Medium and Hashnode each have their own canonical / original-URL setting, in their own corner of their own UI.
Bluesky, LinkedIn, Hacker News and Reddit don't copy the post at all. They're just posts that link to you.

None of that is hard. It's tedious, which is worse. Tedious work gets done by hand, a little differently each time, and then forgotten. A missing or slightly-off canonical doesn't throw an error or show a warning. It just sits there.

And nobody goes back three months later to re-check.

salahxd.dev is the original. The copies point back to it, and the posts link to it.

The first thing castio caught was my own site

Building castio's canonical check meant looking hard at my own site first, and it didn't pass.

My site linked to posts without a trailing slash, but the canonical tag on each post used the URL with one. So every post had two URLs, /blog/some-post and /blog/some-post/. A person would call those the same page. A crawler sees two different URLs.

castio compares the live canonical against the expected URL exactly, so none of my posts would ever have been marked Ready until the two agreed. I fixed the site, and links now end in /. The dashboard now says it right under the URL pattern field: "The trailing slash matters." I wrote that line for myself first.

The other honest one: I have an older DEV article whose canonical I still need to fix by hand. castio only manages what it publishes, so that one's on me.

Push, wait, approve, publish, verify

Here's the whole flow, in the order it happens.

Push. I write the way I always have: an Astro site, posts as files in src/content/blog, in a GitHub repo. castio is a GitHub App installed on that one repo with read-only Contents access. When I push, a webhook tells castio a post was added or changed. castio verifies the webhook signature before it trusts any of the payload.

Wait. A push isn't a deploy. castio keeps checking the live URL until the post is actually up and its <link rel="canonical"> matches the expected URL exactly. Only then is the article Ready. It never distributes a post that isn't live yet, so no cross-post ever points at a 404.

Approve. The preview shows exactly what each platform will receive. Nothing goes out without my approval. I can send it now or schedule it, in my timezone.

Publish. Two platforms are fully automatic:

DEV goes through the API with canonical_url set. I can publish or save as a draft, with an optional "Originally published at" footer.
Bluesky gets a post with a link card, built from a template with {title} and {excerpt}. It connects with proper atproto OAuth, with no app passwords.

LinkedIn, Hacker News, Reddit, Medium and Hashnode get copy-paste kits. castio prepares everything, then I post it and mark it done. I never set out to automate every platform. What I wanted was to know where every copy lives.

Verify. After publishing, castio fetches every copy and checks that its canonical points back to the original. Then it checks again every day. If a copy drifts, it gets flagged as needing action and I get a notification, plus an email if I've turned that on.

That last step is the one I actually care about. Everything before it saves me time. Verification is the part I'd never do myself.

From git push to verified copies. The only manual steps are approving, and posting the kits.

One more boring detail I'm glad I handled early: secrets like the DEV API key are stored encrypted under a versioned keyring, so keys can be rotated, and they're never shown again once saved.

Failures are per platform, not all-or-nothing

The easy way to build this is one big "distribute" job that either works or doesn't. That's the wrong shape. If Bluesky has a bad minute, DEV shouldn't care.

So every platform gets its own publication with its own state:

The automatic path is draft → queued → publishing → published → verified.
If publishing fails, it goes to failed, then back to queued for a retry.
If something goes wrong while publishing, or later with a published or verified copy, it lands in needs_action. From there it goes back to queued, or on to verified once it's sorted.
Copy-paste kits take their own path: draft → manual_pending → manual_done → verified.
Anything not sent yet can be skipped.

Written down, that's a lot of states. In practice it means a failure is one row with one clear next step. I never have to wonder what did and didn't go out.

One state machine per platform. A failure on one never blocks the others.

One Docker image, three jobs

The stack is a pnpm + Turborepo monorepo. There's a NestJS API, a BullMQ worker, Postgres via Drizzle, and Redis. The dashboard is Next.js with the App Router and TanStack Query.

The API and the worker ship as the same Docker image. So does the migration step:

node dist/start.js api
node dist/start.js worker
node dist/start.js migrate

Migrations run on start behind a Postgres advisory lock, so two containers booting at the same moment never both try to migrate.

The browser only ever talks to one origin. The dashboard lives on Vercel at castio.salahxd.dev and rewrites /api/* to the API at castio-api.salahxd.dev. The API runs next to the worker on my VPS, deployed with Dokploy. The GitHub push webhook skips the dashboard and goes straight to the API domain.

Tests run against real Postgres and Redis through Testcontainers, with no mocked database quietly agreeing with everything.

The dashboard on Vercel, the API and worker on my VPS. One image, one browser origin.

Four things that broke on the way to production

None of these were bugs in the logic. All of them showed up at deploy time.

1. GitHub webhooks are bigger than you'd expect. A push webhook can be up to 25 MB. Express and Nest default to a 100 kb JSON body limit. I gave only the webhook route a 25 MB parser, and every other route keeps 100 kb. The gotcha is that Nest silently skips registering its own body parsers if it finds a middleware function named jsonParser. So the wrapper got a different name.

2. Multi-line secrets don't survive every env editor. I pasted the GitHub App's PEM private key into Dokploy's env editor, and only the first line survived. To its credit, Octokit's error said exactly that: the key "contains only the first line". The fix was to store it on one line with literal \n and let the config turn those back into real newlines.

3. Certificates can race your DNS. Let's Encrypt tried to issue the API's certificate before the DNS record existed. It got NXDOMAIN, and Traefik fell back to serving its default cert. Nothing retries on its own. Once DNS resolves, you have to nudge Traefik into trying again, which in Dokploy means re-saving the domain.

4. Next.js rewrites are decided at build time. Rewrites are baked in when you build, so the API URL has to exist during the build. Turborepo's strict env mode silently drops any env var not declared in turbo.json. One line fixed it:

"env": ["API_INTERNAL_URL"]

Three of those four failed quietly, with no crash and no warning. Things just weren't right. Silent drift is exactly the problem castio exists to catch in canonicals.

This post is the first one castio ships

castio is v0. I built it for my own site first, and that's the only site it runs on. If it earns its keep here, it might turn into something other developers can use. No promises.

If you're reading this on DEV or Bluesky, castio put it there, and the canonical points back to salahxd.dev. View the source if you like. castio already checked it, and it'll check again tomorrow.

If you'd want something like this for your own blog, tell me. That's the only signal I'm looking for.

Originally published at salahxd.dev.

Meet Archify

Mohd Salahudeen — Wed, 01 Jul 2026 19:31:45 +0000

A couple of weeks ago I wrote that Archify was coming and asked people to join a waitlist. That post ended with "coming soon."

This one doesn't. Archify is live. It's a Chrome extension, you can install it right now, and it does the thing I promised: you hover over any web app and it tells you how the app is built — without a single byte leaving your browser.

Ten seconds, not an afternoon

The old routine for understanding an unfamiliar app is archaeology. Open DevTools, inspect elements, dig through the network tab, hunt for source maps, trace API calls across a dozen tabs until a mental model finally clicks.

Archify collapses that into a hover. Install it, open any site, and move your cursor over the page. An overlay follows along, and for whatever you're pointing at it shows:

The framework behind it — React, Next.js, Vue, Angular, Svelte
The component type — dialog, menu, button, input, tooltip
The UI library — MUI, Ant, Bootstrap, Chakra, Radix
The recent API calls the page has made — method, path, status, latency

Click to lock the overlay in place so you can read it properly. Press Escape to let it follow your cursor again. That's the whole interaction.

Every claim comes with a confidence — and it never makes names up

This is the part I care about most, and it's the reason Archify took longer than a weekend.

Most detection tools guess confidently and are wrong just often enough to waste your time. Archify does the opposite. Every claim it makes carries a confidence score, and when it can't actually prove something, it says unknown instead of inventing an answer.

On a development build it can be specific. On a minified production bundle — where the component was named a and the class is css-1q2w3e — it will not fabricate a component name to look smart. It tells you what the runtime can actually prove and marks the rest honestly.

My favorite example is shadcn/ui. At runtime it's just Radix primitives with Tailwind classes pasted in — genuinely indistinguishable from raw Radix once it's shipped. So Archify says Radix, and offers shadcn only as a low-confidence hint with a note explaining why it can't be sure. A tool that admits what it doesn't know is worth more than one that's confidently wrong.

The second tab I didn't mention last time: Security

The waitlist post was all about architecture. Here's the part I saved: there's a second tab, and it changes the question from "how is this built?" to "what is this page doing to me?"

Switch to Security and, for the page you're on, you get:

Third-party scripts — how many of the scripts running here come from someone other than the site itself
Outbound calls — how many network requests go out, and to how many third-party domains
Form and payment field access — and this is the sharp one: which scripts are in a position to read your password, card number, or CVC fields

That last one works by watching which script attaches a listener to a sensitive input, and naming where that script came from. It's not an accusation — a script reading a field can be perfectly legitimate. It just makes visible something that is normally invisible: who is technically able to see what you type. Point it at a checkout page you don't run and you may find that list longer than you'd like.

Nothing leaves your browser

Everything above happens locally. There is no cloud step, no server-side analysis, no source upload, no account, and no telemetry. Archify intercepts fetch and XHR, reads the framework globals, and inspects the DOM — all inside your tab — and renders the result right there.

That isn't a privacy promise stapled onto the marketing. It's the architecture. There is no "other end" to send your code to, because I never built one. The systems you explore stay entirely yours.

What's not in it yet

Honesty cuts both ways, so: v1 is deliberately small. There's no AI "explain this app" mode, no architecture graph, and no exports. It's Chrome-only for now. Those are on the roadmap, not in the box — and I'd rather ship something small and honest than something impressive and vague.

Install it

If you've ever opened DevTools and wished the app would just explain itself, this is for you. It's free, it's local, and it installs in a click.

Install Archify at archify.salahxd.dev — then open any site, hover, and see what it's actually made of. Software shouldn't be a black box.

See Through Any Web App

Mohd Salahudeen — Mon, 22 Jun 2026 14:36:49 +0000

For most of software's history, writing code was the bottleneck. Today, understanding it is.

AI can generate thousands of lines in seconds. Frameworks abstract away the hard parts, libraries hide their internals, and a single page pulls in dependencies that almost nobody ever opens and reads. We got very good at producing software, and we did almost nothing to make it easier to understand. That gap is the problem I kept running into — so I built a tool for it: Archify.

The questions that should take seconds

Every day, developers lose hours to questions that have exact answers:

What component is rendering this?
Where is this data coming from?
Which API powers this feature?
What third-party scripts are running on this page?
What can actually reach user data?

The answers all exist. They're just buried under layers of abstraction — scattered across DevTools panels, source maps, network tabs, and a repository you may not even have access to.

Understanding software shouldn't feel like archaeology

When you land on an unfamiliar app, the routine is always the same. Open DevTools. Inspect elements. Dig through network requests. Search the source maps. Trace the API calls. Jump between docs, repos, and a dozen browser tabs until a mental model finally clicks into place.

The information was never the hard part. Modern tooling is excellent at exposing implementation details — the individual requests, the minified bundles, the raw responses. It's far worse at exposing architecture: how those pieces actually connect. That's the part you end up reconstructing by hand, every single time.

What Archify does

Archify is a browser extension that shows you what's actually happening behind any web app. Hover over an element and you instantly see:

The component rendering it
The framework or library behind it
The API connections powering it
The scripts running on the page
How those parts relate to each other

Instead of spending an afternoon tracing behavior across tabs and files, you get the architecture directly — not just what exists, but how it fits together.

Built for understanding, not surveillance

Most developer tools start from the assumption that your data should leave your machine. Archify doesn't. It runs entirely inside your browser:

No cloud processing
No server-side analysis
No source code uploads
No accounts
No hidden telemetry

The systems you explore stay yours. That isn't a marketing line — it's the architecture. There's nothing on the other end to send your code to.

Why this matters now

The industry is mid-shift. Generating code is becoming nearly free, but generated code still has to be reviewed, dependencies still have to be trusted, and applications still have to be understood. The ability to build is accelerating. The ability to comprehend isn't. Every day, that gap widens.

I think the next generation of developer tools won't be judged by how much code they can write. They'll be judged by how quickly they help you understand what already exists. That's what Archify is for: making the act of understanding a piece of software as fast as the act of using it.

Coming soon

Archify is getting ready for launch, and I'm inviting early users in now. If you've ever opened DevTools and wished the app would just explain itself, you're exactly who I'm building this for.

Join the waitlist at archify.salahxd.dev — be among the first to try it, and help shape what it becomes. Because software shouldn't be a black box.

My Site Has No Database, But It Has a CMS, Comments, Likes, and Views

Mohd Salahudeen — Thu, 11 Jun 2026 18:30:00 +0000

The title isn't a trick. My site has a full CMS with an admin panel at /keystatic, real comments under every post, a like button that remembers you, and view counters that tick up. And there is no database behind any of it — at least, none that I run.

No server I deploy, no database I provisioned. I've never written a migration for this site, never tuned a connection pool, and there's no disk that can fill up at 3am and page me.

That last part was the whole design goal. I'm building a startup, and whatever attention I have left over is not going toward babysitting infrastructure for a personal blog. So I gave myself one rule when building this: if a feature needs me to operate something, it doesn't ship.

What surprised me is how little I had to give up. The whole thing builds to static files and sits on a CDN — but every piece of state you can touch here still gets saved somewhere durable. The state didn't disappear. I just stopped owning the places where it lands.

This is not a genius-architecture post. Most of it is me being lazy in a useful direction. But it works well enough that people ask about it, so here's how each piece fits together.

The CMS is just git

The blog runs on Keystatic. When I open /keystatic in production and hit save, it doesn't write to a database. It makes a commit to this repo through a GitHub App:

// keystatic.config.ts
storage: import.meta.env.DEV
  ? { kind: 'local' }
  : { kind: 'github', repo: 'Salah-XD/personal-portfolio' },

In dev it writes files to my local disk. In production it commits straight to GitHub. The post you're reading is a .md file in src/content/blog/. My /now and /uses pages are JSON files in the same repo, edited through the same admin UI.

So my "content database" is the git history. Publishing is a commit. Fixing a typo is a commit. Undoing a bad edit is git revert. Vercel sees the push and rebuilds. I get diffs, blame, and backups for free, from the version control I was going to use anyway.

The catch: writes are slow in the way a deploy is slow. Hitting save kicks off a rebuild, so "publish" takes about a minute. For a blog, I genuinely don't care. If that minute bothered me, this whole setup would be the wrong choice.

The comments are GitHub Discussions in a trench coat

The comment box at the bottom of each post is Giscus, a thin shell over GitHub Discussions. Each post maps to a Discussion thread in the repo. When you comment, you're posting to GitHub, signed in as yourself.

So my "comments table" is a Discussions tab, my spam protection is GitHub's, and my auth is OAuth somebody else built. If the env vars aren't wired up, the component renders a placeholder instead of breaking:

{giscusReady ? (
  <Comments ... />
) : (
  <p>Comments will appear here once Giscus is configured.</p>
)}

There's a real downside here and I want to be upfront about it: you need a GitHub account to comment. For a blog where the readers are mostly developers, that filter costs me almost nothing and kills spam dead. If I were writing for a general audience, it would be a terrible choice.

Okay, confession: the like button does touch a server

The likes and views from the title are the one kind of state on this site I couldn't fake at build time — a view happens when a person shows up, and there's no way around counting it live. So those two features hit Upstash Redis through the only two routes on the site that aren't static:

export const prerender = false; // this route becomes a Vercel Function

const count = await redis.incr(`likes:${slug}`);

That's the entire data model. Two integer keys per post — likes:slug and views:slug — and the only operation is INCR. No schema, no ORM, no tables. Deduping is a cookie, not a query: 30 minutes for views, a year for likes. Someone clearing their cookies can like a post twice. I can live with that.

And the Redis layer is optional. If the keys aren't set, it degrades instead of crashing:

// lib/redis.ts
const url = process.env.KV_REST_API_URL ?? process.env.UPSTASH_REDIS_REST_URL;
const token = process.env.KV_REST_API_TOKEN ?? process.env.UPSTASH_REDIS_REST_TOKEN;

let _redis: Redis | null = null;
if (url && token) _redis = new Redis({ url, token });

export const redis = _redis;
export const isRedisConfigured = _redis !== null;

So yes — strictly speaking, "no backend" is false. There are two serverless functions and a managed key-value store. But Upstash speaks plain HTTP and bills per request, so there's nothing to keep alive between visitors. I provisioned it by clicking a button on a marketplace page. I have never operated it. That feels meaningfully different from "running a database," even if a pedant would disagree.

Everything else happens before anyone visits

The rest of what looks dynamic is work done once, at build time:

Search is Pagefind — it indexes the built HTML and ships a static index the browser queries. No search server.
The OG image on every post is rendered with satori + resvg during the build. No screenshot service.
RSS and the sitemap are just generated files.

When a request comes in, almost none of this code runs. It already ran, once, on my machine and on Vercel's build servers.

What this actually costs me

None of this is free, it's just paid in a different currency:

No instant writes. Publishing is a deploy. Fine for a blog, useless for anything interactive.
No queries. I can increment a counter. I can't ask "which posts did people who liked X also read." If I ever want that, Redis with two keys per post isn't the answer.
More vendors, not fewer. Instead of one database I run, I depend on GitHub, Upstash, Vercel, and Buttondown for the newsletter. My bet is that each of them runs their slice better than I'd run all of it — and if one of them dies or gets unbearable, I'm swapping one small piece, not migrating a monolith.

When I'd throw this whole thing out

The moment this site needs user accounts, per-user data, anything transactional, or writes that have to show up in the same second — I'd set up a real database and not feel bad about it. This setup works because a personal blog is read-heavy, write-rare, and has exactly one author. Those are narrow conditions.

But they describe most personal sites and content sites. And for those, the best backend is the one you stop thinking about after the first week. Mine has been a rebuild and an INCR ever since, and I haven't thought about it once.