DEV Community: Syed Mujtaba

Your CI is red because of code you didn't write

Syed Mujtaba — Mon, 02 Nov 2026 14:53:10 +0000

TL;DR: Added a markdownlint check to 33 repos at once — and woke up to ~100 CI failure emails about code I didn't write. The fix: lint only the files changed in the PR, never the whole backlog. Grandfather existing violations; enforce the standard on new changes.

I maintain a GitHub org with 33 open-source repos. Last month I decided to do the responsible thing: add a default markdownlint check to every repo so our docs stay consistent.

By the next morning I had ~100 failure emails in my inbox. Here's what went wrong — and the rollout playbook I'd use instead.

What happened

The lint workflow ran against every markdown file in each repo — READMEs, changelogs, and contributor guides written years ago by people who had never heard of markdownlint. Upstream markdown, as it turns out, has never passed a linter in its life. Trailing spaces, inconsistent heading levels, bare URLs — the works.

My inbox became a firehose of red X's on code I didn't write, in files I'd never touched, for rules nobody on those projects had agreed to.

The noise-vs-signal problem

This is the classic failure mode of adopting tooling across many repos at once:

Signal: "the file you just edited violates the style guide"
Noise: "a README from 2021 has trailing whitespace"

When 95% of failures are noise, people stop reading CI results entirely — and then the 5% that matter get ignored too. A check everyone ignores is worse than no check at all.

The fix: scope linting to the files you own

Instead of linting the whole repo, I changed the workflow to lint only files changed in the PR:

- uses: actions/checkout@v4
- name: Get changed files
  id: changed
  uses: tj-actions/changed-files@v44
  with:
    files: |
      **/*.md
- name: Lint changed markdown
  if: steps.changed.outputs.any_changed == 'true'
  run: npx markdownlint-cli ${{ steps.changed.outputs.all_changed_files }}

Overnight the emails stopped. CI went green on every repo, and the check still catches every new violation — which is the only thing it was ever supposed to do.

The broader lesson: a playbook for rolling out tooling across many repos

Never lint the backlog on day one. Grandfather existing violations; enforce the standard on new changes only.
Scope every check to what the PR touches. Changed-files linting, diff-aware tests, incremental type checks — same principle everywhere.
Disable noisy upstream workflows you don't own rather than letting them train everyone to ignore red.
Keep the checks you own green. A green build people trust beats a "thorough" build nobody reads.
Roll out repo by repo if you can — 33 repos at once multiplies every mistake by 33.

Your CI should tell you about your code. The moment it starts yelling about code you didn't write, scope it down until the signal comes back.

Have you ever been buried by a noisy CI rollout? What did you do about it — scope it down, fix the backlog, or turn the check off? Tell me in the comments. 👇

Migrating 330 digital products between platforms: what broke and what I'd do differently

Syed Mujtaba — Wed, 28 Oct 2026 13:18:13 +0000

TL;DR: Migrated 330 records (305+ products, 39 bundles) from a legacy platform (Entrepedia) to a Next.js + Prisma + MySQL stack. The code was fine — the data was the problem: slug collisions, duplicate titles, cover/deliverable mismatches, and a tangled taxonomy. Scroll to "The checklist I'd use next time" for the actionable part.

Earlier this year I migrated 305+ digital products and 39 bundles from Entrepedia to a new Next.js + Prisma + MySQL platform — idesire.io. Catalog migrations look boring until 330 records disagree with each other. Here's an honest breakdown of what broke, how we fixed it, and the checklist I'd run next time.

What broke

1. Slug collisions

Two products, one slug. The legacy platform allowed duplicate slugs across categories, so /products/planner existed twice. On the new platform the slug is the primary lookup, so imports silently overwrote each other.

Fix: namespaced slugs per category during import, then ran a uniqueness pass and 301-redirected the losers.

2. Broken legacy records

Years of manual edits left products with missing descriptions, null prices, and orphaned category IDs pointing at categories that no longer existed.

Fix: a validation report before import — every record got a health check, and anything failing went into a quarantine list for manual review instead of failing the whole batch.

3. Cover / deliverable mismatches

The cover image said "2024 Ultimate Bundle" while the attached deliverable was the 2022 version. Nobody noticed because nobody re-downloaded after uploading.

Fix: spot-checked a sample of high-traffic products and re-exported covers from the actual deliverables.

4. Taxonomy cleanup

Seven overlapping category trees ("Marketing", "marketing", "Digital Marketing", "MKTG"…) had grown over the years. Search and filtering were useless.

Fix: collapsed everything into one canonical taxonomy and mapped legacy categories with a lookup table — kept the old names as redirects so bookmarks didn't die.

5. Duplicates with exact titles

The same product imported twice under slightly different SKUs, with byte-identical titles. Customers saw the same item twice in search.

Fix: dedupe pass on normalized title + file hash before import.

6. Free pricing enforcement

"Free" products carried stale prices — $0.00 in one field and $19 in another. Checkout logic picked whichever it read first.

Fix: single source of truth — an is_free flag drives the price, and the import rejected any record where the two disagreed.

7. Thumbnail issues

Mixed aspect ratios, oversized images on listing cards, and a handful of hotlinked images that died when the old CDN was shut off.

Fix: regenerated thumbnails at fixed sizes during import and replaced hotlinks with locally hosted copies.

Root causes

Every item above traces back to one of three root causes:

We trusted the legacy data. Years of manual edits had made the old database the least reliable source of truth — and we treated it as gospel.
Implicit rules became import logic. The old platform tolerated duplicate slugs, dual price fields, and loose taxonomy. The new one couldn't. Nobody had written those rules down until they bit us.
We validated after the import, not before. We found problems by reading broken pages instead of by reading a validation report.

The checklist I'd use next time

[ ] Audit the legacy data before writing a line of migration code — export everything to a spreadsheet first
[ ] Write a validation report: every record passes or goes to quarantine; nothing silently drops
[ ] Normalize and dedupe on (title, file hash), not on IDs you don't trust
[ ] Plan the slug strategy up front: uniqueness rules + 301 redirects for collisions
[ ] Freeze the taxonomy first — one canonical tree, legacy names mapped, not merged
[ ] Verify deliverables match their covers on a sample of top-selling products
[ ] Make pricing a single source of truth (is_free flag, not two price fields)
[ ] Regenerate all media at import time — fixed sizes, local hosting, no hotlinks
[ ] Dry-run the full import on staging, then diff staging vs. legacy record by record
[ ] Keep the old platform read-only (not deleted) for 90 days as a reference

Migrations are 20% code and 80% data archaeology. The checklist is the part I'd never skip again.

What broke in your last migration? Share your war stories in the comments — the messier, the better. 👇

The open source references I keep in my own account (standalone editions, honestly labelled)

Syed Mujtaba — Fri, 23 Oct 2026 23:52:04 +0000

Quick honesty note before anything else: none of the projects below are mine. They are well known open source references that I keep as standalone editions in my GitHub account, each one credited to its upstream project in the repo description and README, because I actually use them in my daily work as a full-stack developer.

Why keep your own editions at all? Three reasons. My tooling keeps working even if an upstream repo moves. I can pin the exact version my workflow depends on. And I add a small enhancement layer on top: standardised docs, dependabot, CI and lint, so every edition behaves the same way in my setup.

The ones that earn their keep:

public-apis, standalone edition (https://github.com/mujtbabbas/public-apis)
The collective list of free APIs. Original: public-apis/public-apis. I reach for it at the start of almost every integration.

free-for-dev, standalone edition (https://github.com/mujtbabbas/free-for-dev)
Free tiers of SaaS, PaaS and IaaS offerings. Original: ripienaar/free-for-dev. It pairs well with my own FreeDomain list if you are bootstrapping a side project at zero cost.

markitdown, standalone edition (https://github.com/mujtbabbas/markitdown)
Microsoft's tool for converting files and office documents to Markdown. Original: microsoft/markitdown. It sits in the middle of my document pipelines.

ui-ux-pro-max-skill, standalone edition (https://github.com/mujtbabbas/ui-ux-pro-max-skill)
A design intelligence skill for AI assisted UI work. It shapes how I brief design tasks before writing code.

If you use these tools too, star the ORIGINALS first, they earned it. If my editions are useful to you, a star there helps me justify the maintenance time. And if you maintain similar reference editions, I would like to hear how you handle upstream updates in the comments.

Building in public from Skardu: the production systems behind my GitHub

Syed Mujtaba — Fri, 23 Oct 2026 19:34:36 +0000

I am a senior full-stack developer in Skardu, Pakistan. A lot of my client and product code lives in private repos, but the public side of my GitHub is bigger than I realised, and until this week almost none of it had been shown to anyone. Here is what is actually public and worth a look.

FreeDomain (https://github.com/mujtbabbas/FreeDomain)
A curated list of free domains, DNS, hosting and developer resources for side projects. It is the repo I maintain for the community, and this week it went from 1 star to 14 because people finally saw it.

POS System (https://github.com/mujtbabbas/pos-system)
A complete point of sale system for retail: sales, inventory and daily closing. Boring on paper, used every single day, which is the highest compliment business software can get.

Hostel Management System (https://github.com/mujtbabbas/Hostel-Management-System-Laravel)
An end to end Laravel system for hostels: tenants, rooms, billing and the daily admin that eats hours when it lives in spreadsheets.

CreativeAI (https://github.com/mujtbabbas/CreativeAI)
An experimental AI driven creative platform, my sandbox for testing modern AI tooling in a real product shape instead of demo notebooks.

Alongside these I also keep standalone editions of well known open source references (public-apis, free-for-dev, markitdown and others) in my account, each credited to its upstream project, because I use them daily in my own work.

If any of the public projects look useful, a star genuinely helps other people find them. Questions and feedback are welcome in the comments.

Free domains for side projects: what actually works in 2026 (from maintaining a curated list)

Syed Mujtaba — Thu, 22 Oct 2026 19:31:58 +0000

Every side project hits the same wall: you need a domain and a few basic services before you have even validated the idea, and the "free" options are scattered across dozens of sites, half of them outdated.

I maintain FreeDomain, an open-source curated list of free domain options and free developer resources — free subdomains, DNS, hosting and the small services you need to get a project live at zero cost. I keep it updated because I build a lot of small products myself (a flight-booking platform, a learning-products platform, a few SaaS tools) and I kept re-researching the same free tiers.

What I have learned maintaining it:

Free subdomains are fine for validation; move to a paid domain the day real users arrive.
Always read the renewal terms — "free for year 1" and "free forever" are very different things.
Keep a note of where each project's DNS lives. Future-you will not remember.

The list is here: https://github.com/mujtbabbas/FreeDomain
If it saves you time, a ⭐ on the repo helps other developers find it — and I am working towards a small GitHub milestone with it. Additions and corrections via PR are welcome.

Hello DEV, I'm Mujtaba — full-stack dev building travel & learning platforms from Pakistan

Syed Mujtaba — Thu, 22 Oct 2026 13:56:52 +0000

For years I've been building booking platforms and e-learning marketplaces from Pakistan — quietly shipping, rarely writing. Today that changes: hello, DEV! I'm Mujtaba. 👋

I'm a full-stack developer, and I figured the best introduction is to show you what I spend my days on.

What I do

Senior Full-Stack Developer at Gravité
Founder of Divine Fly, a travel tech company

My stack

Next.js · Laravel · Node · PHP · MySQL

What I'm building

divinefly.pk — a full booking platform for travel: flights, hotels, and holiday packages.
DivineFly Desk — an internal Laravel app that powers our operations behind the scenes.
idesire.io — an e-learning platform with 330+ digital products, recently migrated to a Next.js + Prisma + MySQL stack.

What I'll be writing about

Platform migrations — I just moved 305+ products and 39 bundles between platforms. War stories incoming.
Web security — I do security audits, so expect practical hardening guides, not just theory.
Platform engineering — lessons from building booking and learning products that have to work at scale.

I'm here to share what I learn in the trenches and to learn from this community. If that sounds like your kind of thing, hit follow — I'd love to have you along for the ride.

What are you building right now? Say hi in the comments — let's connect. 👇