← Abdelrahman Saed
Articles
Tutorials and field notes on mobile engineering, Flutter, and the CI/CD automation that keeps releases boring. 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. — A two-workflow radar that refreshes every open PR on each merge to master, treats mergeability as eventually consistent, and routes conflict alerts to the right person.
- 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 — Bulk branch deletion done safely, as a careful classification with a per-run cap, deferral, and a full audit trail — never a blunt age filter.
- 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 and local-first get used interchangeably, but they answer different questions — one is about whether the app works with no network, the other about who owns the canonical copy of the data. Where the line falls, 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 — A hands-on guide to cached, offline-capable, native PDF viewing in Flutter with flutter_cached_pdfview — from the package's creator and maintainer.
Available for hire. Abdelrahman Saed is a Senior 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