Writing

Evidence of technical authority — mobile architecture, CI/CD, and offline-first deep dives from 5M-user production work. 11 articles and counting.

The Self-Driving Repo

A CI/CD automation series: small GitHub Actions that run the boring, error-prone parts of engineering — guardrails, PR hygiene, a merge-conflict radar, safe cleanup — so releases stay calm.

Part 1: The repo that rejects my own pushes to master — Two small GitHub Actions that stop accidental direct pushes to master and auto-restore build-breaking files — reversible by design, with an explicit escape hatch.
Part 2: PRs that fill in their own paperwork (and a gate that won't let bad code merge) — Separating the chores of code review from the judgment: auto-context on every PR, plus a quality gate that validates translations, runs the analyzer, and cleans up after itself.
Part 3: Making Jira and GitHub agree without anyone updating both — A branch-name regex and one REST call mirror Jira status, fix versions, and labels onto every PR — plus a Slow PR flag that surfaces finished work that is not shipping.
Part 4: Every merge to master quietly breaks other PRs. So I built a radar for it. — Two GitHub Actions workflows that rebase every open PR on each merge to master and route conflict alerts to the right author — so merge conflicts never sit unnoticed.
Part 5: I let a bot resolve merge conflicts and push the fix. Here's how I made that safe. — How to ship a genuinely dangerous automation safely — by shrinking its blast radius to one provably-safe case, working only in throwaway space, and failing closed on anything unexpected.
Part 6: A repo that cleans up after itself — without deleting the wrong branch — A GitHub Actions workflow that classifies and deletes stale branches safely — per-run cap, deferral window, and a full audit trail. No accidental deletes.
Part 7: I built an AI that writes weekly engineering summaries. Then I had to decide whether I should. — Aggregating git and Jira into per-person weekly summaries with an LLM is a weekend project. Doing it responsibly — private, descriptive, transparent — is the actual work.

More writing

Offline-First vs Local-First: What's the Difference? — Offline-first vs local-first: one is about working with no network, the other about who owns the canonical data — with examples from a 5M-user Flutter app.
Best Practices for Managing Large Flutter Codebases — Hard-won lessons from scaling iStoria — a 220K+ line, 60+ module Flutter app serving 5M+ learners — into a codebase a small team can still ship weekly.
App Flavors in Flutter: One Codebase, Every Environment — How to run local, staging, and production from a single Flutter codebase with build flavors — Dart entry points, typed per-flavor config, and the Android and iOS native wiring that makes it real.
Building a Cached PDF Viewer in Flutter — How to load a PDF from a URL in Flutter with fast native rendering, on-device caching, and offline support — a flutter_cached_pdfview guide from its author.

Resources

Flutter Reference — glossary, comparisons & guides — definitions, head-to-head package comparisons, curated directories, and architecture guides.

Available for hire. Abdelrahman Saed is a Lead Mobile Engineer (Flutter) — open to full-time, fractional, contract, or advisory work. Hire me →

Book a 20-minute call · Download the CV (PDF) · See how I work