DEV Community: Mohamed Ismail

Why I Switched from ts-rest to oRPC

Mohamed Ismail — Fri, 23 Oct 2026 07:30:32 +0000

I've been using ts-rest for a while, and I genuinely liked it.

Contract-first APIs, end-to-end type safety, OpenAPI support, and a clean developer experience. It had pretty much everything I needed.

But over time, I started having concerns about its maintenance. Development seemed to slow down, updates became less frequent, and I was looking for better Zod 4 support.

It was still a good library, but I didn't want to start my next project with something I was already uncertain about.

So I started looking for alternatives.

tRPC or oRPC?

The two options that caught my attention were tRPC and oRPC.

tRPC is a solid choice. It's mature, has a great developer experience, and works really well with TypeScript and TanStack Query.

But I wanted something more.

I didn't want to give up OpenAPI. My backend might eventually serve a mobile app, a Python service, or external integrations.

tRPC can support OpenAPI through additional tooling, but I wanted it to be a first-class feature.

That's where oRPC stood out.

What I liked about oRPC

After exploring the official comparison and documentation, a few things caught my attention.

1. RPC + OpenAPI

Define procedures once and expose them through RPC or OpenAPI-compatible HTTP endpoints. No need to maintain two separate API implementations.

2. Typed errors

You can define expected errors and get proper TypeScript support when handling them on the client. Really useful when dealing with complex business logic.

3. Better type support

Types like Date, BigInt, Map, Set, and URL work through its RPC serialization without requiring additional transformers. It also supports File and Blob.

4. Streaming

Built-in support for typed Server-Sent Events and streaming responses.

5. Good integrations

Works with TanStack Query, NestJS, Next.js, OpenTelemetry, and more.

6. Performance

The official benchmarks show some impressive results, including roughly 4x the throughput of tRPC in certain scenarios.

Of course, benchmarks don't represent every real-world application, but they're still interesting.

Why I made the switch

My requirements were simple.

I wanted the smooth developer experience of RPC, proper OpenAPI support, typed errors, and the flexibility to build APIs for different clients.

I also liked that oRPC supports contract-first development, something I appreciated about ts-rest.

oRPC gave me the combination I was looking for.

That doesn't mean it's better for everyone.

tRPC is still excellent for TypeScript-only applications, and ts-rest remains a good option for REST-first, contract-driven APIs.

I wouldn't recommend migrating a working application just because another library has more features.

But for my new project, oRPC made more sense.

Final thoughts

I didn't switch because ts-rest was bad or because oRPC was newer.

I switched because my requirements had changed, and oRPC felt like a better fit.

I'm still exploring how it holds up as my projects grow, but so far, I like the direction.

If you're evaluating TypeScript API libraries, I'd recommend checking out oRPC.

Have you tried oRPC in production? I'd love to hear your experience, especially any limitations you've encountered.

I Built a Receipt Printer for Your GitHub Year 🧾

Mohamed Ismail — Fri, 09 Oct 2026 12:17:46 +0000

Press a button. A tiny printer warms up. Paper slides out, and your entire GitHub year lands in your hands as a receipt.

That's Git Receipts, and you can print yours in about ten seconds.

Print your GitHub year →

No sign-in needed. Enter any public GitHub username: your own, a friend's, or a developer you admire.

This is project #1 in Beyond the Green Squares, a series where I turn GitHub activity into fun things you can try and keep.

How it works

Enter a GitHub username or profile link
Pick a year
Press FEED and watch it print
Save it, share it, or print it on real paper

Why a receipt?

Everyone knows what a receipt looks like: a narrow strip of paper, neat rows, dashed lines, and a bold total at the bottom.

It fits a year of GitHub activity surprisingly well. Your contributions become the total. Active days and streaks become small details you can scan at a glance.

And there's something satisfying about it. You press a button, wait for the machine, and get a little object at the end. I wanted that moment to be part of the experience.

A printer that feels like a printer

I didn't want a box with rounded corners. The machine has an off-white body, a dark top deck, a paper slot, status lights, and a FEED button that clicks into place.

The motion matters just as much. Paper has to emerge from the slot, feed through, and get cut at the end. If it floats, the magic is gone.

If you prefer reduced motion, it skips the animation and shows your finished receipt. Sound is off by default.

The numbers stay honest

The design is playful. The data is not.

No guessing. If GitHub doesn't provide a number, it's left off the receipt instead of being estimated.
Samples are labeled. The demo receipt on the landing page is clearly marked as a sample.
Nothing borrowed. If a lookup fails, you see an unavailable message, never someone else's activity.

One more honest note: a contribution count can't capture everything. Reading, planning, learning, and time away from the keyboard all count as real work. The receipt is a keepsake of reported activity, not a measure of you.

Take it with you

When printing finishes, your receipt opens in a full-size viewer. Scroll through it, then keep it however you like:

PNG to share
PDF to print on paper
SVG and plain text
README embed to show it on your GitHub profile

Hit a milestone and your receipt gets an achievement stamp, pressed onto the paper like the real thing. Every receipt also carries a QR code that leads back to it.

Put it on your GitHub profile

Your receipt can live in your profile README, and it follows light and dark mode automatically. Click it and it opens your receipt on Git Receipts.

Copy the README snippet

<a href="https://git-receipts.vercel.app/?user=YOUR_USERNAME&amp;year=2026&amp;stamp=true">
  <picture>
    <source media="(prefers-color-scheme: dark)" srcset="https://git-receipts.vercel.app/api/receipt.svg?year=2026&amp;stamp=true&amp;user=YOUR_USERNAME&amp;theme=dark">
    <img src="https://git-receipts.vercel.app/api/receipt.svg?year=2026&amp;stamp=true&amp;user=YOUR_USERNAME&amp;theme=light" alt="YOUR_USERNAME's 2026 GitHub contribution receipt">
  </picture>
</a>

Replace YOUR_USERNAME in all three places with your GitHub username, and change the year if you want a different one.

Your turn 👀

Print your GitHub year →

Then tell me what caught your eye: your total, your longest streak, or a month you'd completely forgotten about. Add it to your profile README, post your receipt, and tag me. I'd love to see it.

And if you have a unique idea for turning GitHub activity into something worth keeping, drop it in the comments. The best ones might become the next post in Beyond the Green Squares, and we'll build it together.

What should we build next?

Beyond the Green Squares: Turning GitHub Activity Into Things Worth Keeping

Mohamed Ismail — Fri, 09 Oct 2026 12:15:44 +0000

A series of small, playful projects built from your GitHub activity. Try them on your own profile, keep the results, and help decide what I build next.

You push code for a whole year. Late nights, tiny fixes, big launches, reviews for other people's work.

And GitHub shows all of that as a grid of green squares.

Squares are fine. But I keep wondering what that year would look like if it became something you could hold, share, or stick on a wall.

So I'm starting Beyond the Green Squares.

What this series is

Each post is one small project that turns GitHub activity into something unexpected. The rules are simple:

You can try it yourself. Every project works with a public GitHub username, no sign-in needed.
You can keep the result. Download it, share it, or print it.
The numbers stay honest. If data is missing, I won't estimate it. Samples will always be labeled as samples.
I'll show how it's built. What worked, what broke, and what I'd do differently.

The design will be playful. The data will not be.

Project #1 is live 🧾

The first build is Git Receipts, a tiny thermal printer in your browser. Enter a GitHub username, press FEED, and your year prints out as a receipt, paper-feed animation and all.

Read the full story: I Built a Receipt Printer for Your GitHub Year →

Or skip the reading and print your year →

Now I need you 👀

This series gets better with your ideas.

If you have a unique idea for turning GitHub activity into something you'd actually want to share, drop it in the comments. Weird, beautiful, useless, brilliant, all welcome. The ones I can't stop thinking about might become the next post, with credit to you.

So, what should we build next?

dep-blame: Understand How Your Dependencies Changed

Mohamed Ismail — Thu, 08 Oct 2026 04:32:32 +0000

Have you ever looked at a dependency and wondered when it was added, how its version changed, or which commit introduced an update?

I built dep-blame to make those questions easier to answer.

The inspiration came from git-pkgs, a standalone Git tool for exploring dependency history. I wanted to bring that idea into a focused tool for JavaScript and TypeScript projects, with a CLI and a simple local dashboard.

What does it do?

dep-blame reads your repository’s Git history and shows dependency additions, updates, and removals.

You can explore:

When a dependency first appeared in the available history.
How its versions changed over time.
The commit author, date, and message behind each change.
Dependency changes across workspace manifests.
Declared requirements in package.json and resolved versions in lockfiles.

The dashboard includes a searchable table, filters, a calendar, and a history view for individual dependencies.

The dep-blame dashboard makes dependency changes easier to browse and inspect.

Why is it useful?

Imagine your application starts behaving differently after a dependency upgrade. dep-blame helps you locate the version change and its commit, giving you a starting point for investigating the problem.

It also helps when reviewing dependency updates, joining an unfamiliar project, or understanding how an older codebase evolved.

The goal is simple: make dependency history easier to find, read, and understand.

Try it

With Node.js 20+ and Git installed, run these commands inside your project’s Git repository:

# View dependency history in the terminal
npx dep-blame

# Open the local dashboard
npx dep-blame ui

If you’ve ever searched through a long lockfile diff to understand one package update, dep-blame might be useful to you.

Explore the project: GitHub · npm

Looking for a opportunity

Mohamed Ismail — Mon, 21 Sep 2026 13:03:46 +0000

Looking for a freelance or job opportunities! I build modern, scalable, and maintainable full stack applications that are ready for production and built to grow. If you have an idea, a project, or need a developer to help bring your product to life, feel free to reach out — let’s build something great together!

Email: ihssmaheel@gmail.com
Github: ihssmaheel-dev

I Wired the Boring 80% So You Can Build the Interesting 20%

Mohamed Ismail — Wed, 09 Sep 2026 06:01:24 +0000

A ready-to-use fullstack boilerplate built for speed, clarity, and smooth AI-assisted coding.

🔗 Repo: github.com/ihssmaheel-dev/modular-monolith-starter

Why I Built This

We're in a strange, exciting era. Thanks to AI coding tools, a single developer can now attempt projects that used to take a whole team years to build. But there's a catch — most people don't spend weeks stuck on the hard part. They spend weeks stuck on the boring part: wiring up auth, picking the right architecture, connecting the database, configuring queues, and just... getting to a point where they can start building the actual idea.

I've felt that pain myself. So I built this starter to remove it.

The goal is simple: give a solo developer (or a small team) a clean, production-ready foundation on day one — so the setup grind doesn't eat the weeks you should be spending on your actual product.

A Quick, Honest Note Before You Dive In

No two developers build the same way, and that's completely fine. This starter isn't the "one true way" to structure a project — it's my way, shaped by research into other boilerplates, a lot of blog posts, and more than a few conversations with AI tools along the way.

If something here doesn't match how you like to work, change it. Rip out what you don't need, rename what bugs you, restructure what feels off — do it before you start building on top of it, while it's still cheap to change. I'm not asking anyone to use this exactly as-is. I just believe it's a solid, well-thought-out starting point — and I'd rather you shape it to fit you than fight it the whole way through.

The Idea: Clean Modules, One Codebase

Instead of piling everything into one giant folder, this starter splits your app into separate modules — like auth, users, notes, tenancy, files, notifications, and privacy.

Each module follows the same four simple layers:

Presentation – Thin controllers that just validate input and send responses.
Application – The actual logic, like CreateNoteCommand or GetUserQuery, each in its own small file.
Domain – Pure business rules. No frameworks, no database code, just logic.
Infrastructure – Database tables (Drizzle ORM) and repositories that talk to PostgreSQL.

No More Surprise Crashes

Most apps throw errors when something goes wrong — a bad password, a missing user — and one missed try/catch can crash your server.

This starter uses the Result pattern (via neverthrow) instead. Every function returns either ok(data) or err(error). Errors become normal values you handle on purpose, not surprises that break things.

Built for AI Coding Tools

If you use tools like Cursor, Claude Code, GitHub Copilot, or Antigravity, you already know they work best on clean code — and struggle once files get long or types get messy.

This starter is designed with that in mind:

Small files. Routes stay under 150 lines, and use cases stay under 400 — short enough for an AI tool to read in one go.
One source of truth. Every API request and response is defined with Zod schemas in @repo/contracts, so nothing is left to guesswork.
Built-in guardrails. The build catches common mistakes automatically — like a UI component accidentally importing a database model.
Clear instructions. An AGENTS.md file and an ai_instructions/ folder spell out the project's conventions for any AI assistant working in the codebase.

What You Get Out of the Box

API, Two Ways

Use oRPC for fast, type-safe calls with auto-generated TanStack Query hooks, or plain REST for webhooks and third-party integrations. Both share the same underlying logic, so you never write it twice.

Multi-Tenancy, Done Right

Switch between single-tenant and multi-tenant modes with one environment variable. In multi-tenant mode, PostgreSQL's Row-Level Security enforces data isolation at the database level — so even a buggy query can't leak another organization's data.

Roles & Permissions

A full authorization system with roles, ownership checks, and custom policies. Protecting a route is as simple as adding @RequirePermission('notes:read').

Solid Authentication

JWTs with automatic key rotation
Single-use refresh tokens tracked in Redis to stop replay attacks
"Log out everywhere" support
CSRF protection and account lockout against brute-force attempts

No Double Charges

Add @Idempotent() and Redis will catch duplicate requests — so a double-clicked "Submit" button doesn't create two orders.

Reliable Background Jobs

Using the Transactional Outbox pattern, state changes and their events save in the same database transaction. A background worker then pushes them to BullMQ, so nothing gets lost even if the server restarts.

Direct-to-S3 Uploads

Files go straight from the client to S3 or MinIO using a presigned URL — never through your API server. Unused files are cleaned up automatically after 7 days.

GDPR Ready

Users can export all their data in one click, or request full account erasure — profiles are anonymized immediately and data is cleared after a 30-day grace period.

Realtime Updates

WebSockets and Server-Sent Events, backed by Redis Streams, so realtime features scale across multiple servers without missing events.

Shared Design Tokens & i18n

Edit colors, spacing, and fonts once in active.json, and it updates your web CSS, mobile styles, and email templates together. Comes with English, Spanish, and French translations, plus checks that catch missing translation keys.

Built-In Observability

Tracing, metrics, and structured logs are wired in from the start, with ready-made dashboards for viewing traces and logs locally — so you can actually see what your app is doing instead of guessing.

Add a New Feature in Seconds

pnpm generate:feature invoices invoice

This one command scaffolds everything you need:

Validation schemas and API contracts
Domain entities and error types
Database tables and repositories
CQRS commands and queries
REST and oRPC controllers
Frontend API client methods
TanStack Query hooks and UI components
Unit and integration tests

The Stack

I picked every tool here deliberately — modern, open source, and battle-tested. This isn't the full list (that would be a very long table), just the pieces most worth knowing about:

Layer	Technology
Monorepo	Turborepo + pnpm workspaces, TypeScript throughout
Backend	NestJS on Fastify
Validation	Zod (schemas) + neverthrow (`Result` pattern for errors)
API	oRPC (type-safe RPC) with REST as a compatibility layer, docs via Scalar
Database	PostgreSQL with Row-Level Security + Drizzle ORM
Cache & Jobs	Redis + BullMQ
Auth & Security	Argon2 hashing, JWT with key rotation, CSRF protection, rate limiting
Authorization	Custom hybrid engine (roles + ownership + policies)
File Storage	S3 / MinIO with direct-to-client presigned uploads
Email	React Email, with Resend or plain SMTP
Realtime	WebSockets + Server-Sent Events over Redis Streams
Web Frontend	TanStack Start (React 19, Router, Query, Zustand)
Mobile	Expo + Expo Router + NativeWind
UI	Base UI primitives + Tailwind CSS + shadcn-style theming
i18n	react-i18next, with English, Spanish, and French out of the box
Testing	Vitest + Playwright, with architectural boundary checks
Observability	OpenTelemetry, Prometheus, Pino, with Grafana/Jaeger/Loki for local dashboards

All open source, with no vendor lock-in — and every piece here can be swapped out if it's not your taste.

Get Started in 3 Minutes

# 1. Clone the repository
git clone https://github.com/ihssmaheel-dev/modular-monolith-starter.git
cd modular-monolith-starter

# 2. Install dependencies
pnpm install

# 3. Start local services (Postgres, Redis, MinIO, Mailpit)
pnpm docker:up
pnpm docker:init

# 4. Run database migrations
pnpm db:migrate

# 5. Start development servers
pnpm dev

Your API runs at http://localhost:3000 (docs at /api/docs), and the web app runs at http://localhost:5173.

Star It, Try It, Help Shape It

This project is still growing, and I'd love your feedback — bug reports, feature ideas, or just thoughts on what could be better. And remember: if a piece of this doesn't fit how you work, that's completely fine — unwire it, swap it, make it yours before you build on top.

⭐ Star the repo on GitHub
💬 Open an issue to share your thoughts.

Let's build something great together.

I Wired the Boring 80% So You Can Build the Interesting 20%

Mohamed Ismail — Tue, 08 Sep 2026 19:24:39 +0000

Built for the AI era: a production-ready TypeScript modular monolith
with guardrails for robot coworkers.

Every new project starts the same way. You need auth, multi-tenancy,
file uploads, notifications, emails, i18n, a web app, a mobile app,
tests, observability… and three weeks later you're still wiring
boilerplate instead of building the thing that actually matters.

So I built the starter I always wished existed: a production-grade
modular monolith in TypeScript — one repo, one deployable, zero
premature microservices — with all the boring-but-critical stuff
already done. It's open source and free: fork it, change it, make it
yours → https://github.com/ihssmaheel-dev/modular-monolith-starter.
Here's the tour. 🎢

Starting is easy. Surviving is hard.

AI made it possible to build a working app in a weekend. That's amazing —
but it's also where the trouble starts. Once real users, real data, and
real money arrive, so do the questions nobody planned for:

Where does this business rule even live?
Why does changing one screen break three others?
Who can access whose data?
How do we delete a user's data when the law says we must?
How do we ship mobile without rewriting everything?

Speed without structure becomes pain. Every time.

This starter exists so you can have both: move fast on day one, and
still sleep well on day one thousand.

The 10-second pitch

Backend: NestJS 11 + Fastify + PostgreSQL 16 + Drizzle + Redis + BullMQ
Web: TanStack Start (SSR) + TanStack Query + Zustand + Tailwind 4 + shadcn
Mobile: Expo 57 + expo-router + NativeWind (mirrors the web features)
Contracts: Zod 4 schemas shared end-to-end — the compiler catches API drift
Already wired: fine-grained authorization (RBAC + ReBAC + ABAC), multi-tenancy, GDPR tools, notifications, file uploads, one-file reskin
DX candy: one-command bootstrap, a rebrand script, a full-stack feature generator, interactive API docs, local observability stack
AI-native: the repo ships machine-readable architecture laws, so AI assistants write code that actually fits

The architecture: a modular monolith with lite DDD

Big words, simple meaning:

Monolith — one codebase, one deploy. No microservice maze when you have three developers and a dream. You can always split later, when (and if) you actually need to.
Modular — inside that monolith, every feature (auth, notes, files, notifications…) is a strict module with walls around it. Modules never touch each other's database tables. They talk through clean commands, queries, and events — and CI blocks you if you cheat.
Lite DDD — each module has small layers: presentation, application, domain, infrastructure. Just enough structure to keep business logic pure and testable, without the enterprise paperwork.

Simple to start, safe to scale — easy for a new developer (or an AI
agent) to grasp in an afternoon, and solid when the team grows to twenty.

A real backend, not a todo-app demo

Each domain module follows CQRS: thin controllers,
single-responsibility commands and queries, pure domain entities, and
Drizzle repositories. Application code never throws — it returns
neverthrow Results. Boring? Yes. The kind of boring that sleeps
through the night? Also yes.

Already wired behind those modules:

oRPC + REST with parity — type-safe RPC by default, REST fallback during migrations, interactive Scalar API docs at /api/docs
Fine-grained authorization — one vocabulary (notes:create, team:invite…), ownership checks, tenant and department predicates, enforced via decorators and services
Zero-trust multi-tenancy — single or multi-tenant via one flag, automatic row-level isolation, Postgres RLS as defense in depth
Transactional outbox — domain events publish reliably, with retries and a replayable dead-letter queue
Realtime two ways — WebSocket gateway plus user-scoped SSE, with shared fan-out so web and mobile update live
Resilience boring stuff — rate limiting, WAF, circuit breakers, bulkheads, idempotency keys, CSRF, scheduled jobs, Piscina worker threads for CPU-heavy work, health probes via NestJS Terminus
Auth done right — Argon2 password hashing, short-lived Bearer tokens held in memory, rotating refresh tokens and signing keys, SecureStore on mobile, secure server sessions
File pipeline, not just uploads — presigned S3 URLs, generic upload-then-attach with slots for any parent record, and an orphan janitor so abandoned bytes never become a storage bill
Request correlation everywhere — x-request-id flows through logs, error envelopes, and traces, so a user report maps to the exact request in seconds
Transactional email — React Email templates over Resend or SMTP with circuit-breaker failover, previewed locally in Mailpit
GDPR built in — data export, account erasure, organization erasure, immutable audit trail with retention worker
Observability from day one — structured Pino logs, OpenTelemetry traces, Prometheus metrics, and a provider-neutral error sink
i18n on both sides of the wire — backend errors localized through a shared dictionary service with Accept-Language negotiation, the same keys consumed by web and mobile, and CI parity checks so no language ever falls behind

Web + mobile, speaking the same language

The web app (SSR on srvx, file-based routes, dark mode, EN/ES/FR out of
the box) and the Expo mobile app (SecureStore auth, push notifications,
deep links, offline-tolerant queries) consume the same Zod contracts as
the API. Change a schema, and TypeScript yells at every layer that
disagrees. API drift becomes a compile error instead of a 2 a.m. mystery.

Features already living in both clients: auth flows, notes CRUD with
attachments, user management, tenant invitations, notification center
with preferences and live updates, GDPR export and erasure, avatar +
file uploads (presigned S3 URLs via local MinIO), toasts, paginated
data tables, and empty/loading/error states that don't lie to users.

The notes feature doubles as the reference slice: a complete,
production-shaped example — contracts, module, permissions,
translations, tests, web and mobile UI — that new developers read
first and copy when building their own features.

And when it's time to make it yours: change one theme file, run one
command, and the whole product — web, mobile, even emails — wears
your brand.

The complete stack, and why each piece earned its place

Backend

Stack	Why
NestJS 11 + Fastify 5	Modules and DI that mirror the monolith; Fastify for raw speed
PostgreSQL 16	JSON, full-text search, RLS, rock-solid transactions
Drizzle	SQL you can read, types you can trust, migrations you control
Redis 7 + BullMQ	Queues, retries, digests, and scheduled work that survives restarts
Zod 4 + oRPC	One contract language, end to end — drift is a compile error
neverthrow	Errors as values, not hidden GOTO statements
Argon2	Modern password hashing, not legacy bcrypt defaults
Pino + OpenTelemetry + prom-client	Structured logs, traces, and metrics without extra wiring
Nodemailer / Resend + React Email	Transactional mail with failover and real templates
Piscina + NestJS Schedule	CPU-heavy work off the event loop; cron without a sidecar
WebSockets + SSE	Live updates for browsers and phones alike

Frontend

Stack	Why
TanStack Start + React 19	File-based routes and SSR without framework magic taking over — explicit, portable, and easy for AI tools to reason about. No lock-in, no deploy surprises
TanStack Query + Zustand 5	Server state with caching; client state without boilerplate
Tailwind 4 + shadcn + Base UI	Utility styling plus accessible primitives, themed by tokens
react-hook-form + zodResolver	Forms validated by the same schemas as the API
react-i18next + date-fns	Every string and date localized, no hardcoding
Vitest + Playwright	Fast unit tests plus real browser journeys
srvx + nginx	Lean SSR server in front of a production-grade proxy

Mobile

Stack	Why
Expo 57 + expo-router	Real native apps, file-based routes like the web
NativeWind + Tailwind 3	Same design tokens, native rendering
SecureStore + expo-notifications	Hardware-backed secrets; push that actually arrives
Same api-client + contracts	One API language across web, mobile, and server

Platform

Stack	Why
Turborepo + pnpm 10 + TypeScript 6	Fast monorepo builds, one lockfile, strict types everywhere
Docker + MinIO + Mailpit + pgAdmin	Prod-like local infra: S3, inbox, and DB GUI included
Prometheus + Loki + Jaeger + Grafana	Metrics, logs, and traces locally before you need them in prod
Husky + commitlint + Changesets	Clean commits and versioned releases by default
GitHub Actions CI/CD	Typecheck, lint, tests, architecture rules — enforced, not suggested

Nothing trendy-for-trendy's-sake. Everything chosen to make the next
five years easier, not just the next five minutes.

The developer experience is the feature

pnpm bootstrap → deps, env, Docker services, migrations, build. Then pnpm dev. That's it. (An optional idempotent seed creates your first admin.)
pnpm project:init rebrands the whole starter — name, slug, app titles, bundle IDs — so your fork stops looking like a template in minutes, with a dry-run plan before it touches anything.
pnpm generate:feature <module> <feature> scaffolds a full vertical slice: contracts, backend module, API client, web + mobile UI. A new feature stops being a two-day wiring exercise.
Local infra with one command each: Postgres, Redis, MinIO, Mailpit (a fake inbox!), pgAdmin — plus Grafana, Prometheus, Loki, and Jaeger when you want to feel like a platform team.
pnpm rules:check enforces architecture as code: file placement, no stray fetch, locale parity across languages, co-located tests for every data module. The rules bite — I know, they've bitten me.
Production is planned, not improvised: nginx proxy, workers, and migration runners in compose, pg_dump backups with verified restores, secrets via _FILE mounts, traces and logs wired from the start.

Testing without the lecture

API: 119 Vitest files (unit + real-Postgres integration + e2e)
Web: 87 unit and component tests + Playwright journeys
Mobile: 91 logic tests with native modules mocked at one seam
Coverage gates start low and ratchet up. No ceremony, no 3-hour suites.

Built for the AI-assisted era 🤖

Here's the part I'm most excited about. The repo has an
ai_instructions/ folder — mandatory, machine-readable architecture
laws: locked stack, where every file belongs, how errors, i18n, and
tests work. Combined with small single-responsibility files and
end-to-end types, AI assistants stop hallucinating random patterns and
start writing code that fits the codebase on the first try. It turned my
own workflow from "review every line suspiciously" into "review, nod,
merge." The feature generator plus strict contracts plus enforced rules
basically function as guardrails for robot coworkers.

How it makes life simpler, concretely

Last week I needed a full feature with API, web UI, mobile UI,
permissions, translations in three languages, and tests. Old me: two
days. With this starter: scaffold the slice, fill in the business logic,
run the gate (typecheck, lint, test:unit, rules:check,
format:check, build), commit. The checklist does the worrying.

It's still cooking — come help 👨‍🍳

An honest note: this is an active, early-stage project. Mobile component
tests are now in place, coverage keeps ratcheting, docs keep growing —
and next up is a Python-based intelligence layer, so AI features live in
a dedicated service beside the NestJS API. There will still be rough
edges and bugs we haven't met. But everything you need to start
a serious project today is already here and wired.

Get the code in 2 minutes

git clone https://github.com/ihssmaheel-dev/modular-monolith-starter.git
cd modular-monolith-starter
pnpm bootstrap
pnpm dev

That's the whole install. If it helps you, a star on GitHub is the cheapest way to say thanks — and it helps other developers find it too. ⭐

If you try it and something breaks, confuses you, or just smells wrong —
please open an issue on GitHub
or drop it in the comments. Feature requests doubly welcome. The fastest
way to make a starter great is people actually using it and complaining
loudly. 🙂

Happy building — and may your monolith stay modular.

I Built a Library to Sync Browser Tabs

Mohamed Ismail — Mon, 15 Jun 2026 19:58:20 +0000

Here's Why and How to Use It

We've all been there. You're building a web app, everything works fine in one tab — but the moment a user opens a second tab, things start breaking. Cart items disappear. Login state gets out of sync. Background tasks run twice.

I ran into this problem one too many times, so I built tabcoord to solve it properly.

What is tabcoord?

tabcoord is a small library (under 5KB, zero dependencies) that keeps your browser tabs in sync. It gives you shared state, leader election, locks, and an event bus — all working across tabs automatically.

npm install tabcoord tabcoord-react

tabcoord-react uses tabcoord as a peer dependency, so you need both installed.

Built on Top of the Native BroadcastChannel API

tabcoord uses the browser's built-in BroadcastChannel API under the hood — so it's not replacing it, it's building on top of it.

BroadcastChannel is great at one thing: sending raw messages between tabs. But that's where it stops. Everything on top of that — syncing state, persisting it, bootstrapping a new tab that opens late, handling older browsers, working safely in SSR — you'd have to wire up yourself.

tabcoord takes care of all of that:

State management — not just messages, but a real shared store with React bindings
New tab bootstrap — when a tab opens late, it automatically gets the current state from existing tabs
Persistence — state survives page refreshes via localStorage, without you touching it
Leader election and locks — coordination primitives built on the same channel
localStorage fallback — for older browsers or Safari private mode where BroadcastChannel isn't available
SSR safety — no crashes in Next.js or Remix because the server never touches BroadcastChannel

So if you already know BroadcastChannel, tabcoord will feel familiar — it's just everything you'd have had to build on top of it, already done.

Shared State Across Tabs

The core feature is createSharedStore. You define a store once, and every tab that uses it stays in sync automatically.

// store.ts
import { createSharedStore } from 'tabcoord';

export const cart = createSharedStore({
  name: 'cart',
  initial: { items: [] as string[] },
});

Then use it in your React components with useSharedStore from tabcoord-react:

import { useSharedStore } from 'tabcoord-react';
import { cart } from './store';

function CartButton() {
  const items = useSharedStore(cart, s => s.items);

  return (
    <button onClick={() => cart.set(s => ({
      ...s,
      items: [...s.items, 'new-item'],
    }))}>
      Cart ({items.length})
    </button>
  );
}

Open your app in two tabs. Add something to the cart in one tab. The other tab updates immediately — no refresh, no extra setup.

State is also persisted to localStorage automatically, so it survives page refreshes too.

Only One Tab Does the Heavy Work

If you have background polling or periodic API calls, you don't want every tab running them at the same time. That's wasteful and can cause real problems.

leaderElection picks one tab to be in charge. If that tab closes, another one automatically takes over.

import { leaderElection } from 'tabcoord';

const election = leaderElection('background-sync');

election.onElected(() => {
  const interval = setInterval(() => {
    fetch('/api/updates');
  }, 30_000);

  election.onDemoted(() => clearInterval(interval));
});

One tab polls. The rest stay quiet. When the leader closes, a new one steps up.

Preventing Race Conditions with Locks

Sometimes two tabs might try to do the same thing at the same time — like submitting a form or running an import. lockManager makes them take turns.

import { lockManager } from 'tabcoord';

const lock = lockManager('data-import');

await lock.acquire(async () => {
  await runImport(); // Only one tab runs this at a time
});

The first tab to get the lock runs. Every other tab waits. When it's done, the next one goes.

Sending Events Across Tabs

Not everything needs shared state. Sometimes you just want to tell other tabs that something happened — like a logout or a notification.

import { eventBus } from 'tabcoord';

const bus = eventBus('app-events');

// In one tab, listen:
bus.on('user:logout', () => {
  redirectToLogin();
});

// In another tab, fire:
bus.emit('user:logout', { reason: 'session-expired' });

The event goes to every tab instantly. It supports wildcards (user:*) and a replay buffer so new tabs can catch up on recent events they missed.

Works with Next.js and Remix

Server-side rendering is where most tab-sync libraries break. They crash because browser APIs like BroadcastChannel don't exist on the server.

tabcoord handles this cleanly. On the server, stores return your initial values and behave like regular local state. When the page loads in the browser, they connect to the real cross-tab sync automatically. No crashes, no special wrappers needed.

How Does It Compare?

tabcoord vs Native BroadcastChannel

Feature	tabcoord	Native BroadcastChannel
State sync	✅ Built-in	❌ Manual
Persistence	✅ Automatic	❌ Manual
Leader election	✅ Built-in	❌ Manual
Lock manager	✅ Built-in	❌ Manual
Browser fallback	✅ localStorage	❌ None
SSR support	✅ Works	❌ Crashes
Bundle size	4.78 KB	0 KB

Use tabcoord when you need state management, persistence, leader election, or locks.
Use native BroadcastChannel when you just need simple one-off message passing.

tabcoord vs `broadcast-channel` (2k stars, 3M+ weekly downloads)

A popular BroadcastChannel polyfill with basic leader election.

Feature	tabcoord	broadcast-channel
State sync	✅ Built-in	❌ Manual
Persistence	✅ Automatic	❌ Manual
Lock manager	✅ Built-in	❌ Not available
Event bus	✅ Built-in	❌ Not available
SSR support	✅ Works	❌ Browser only
Node.js	❌ SSR only	✅ Full support
Bundle size	4.78 KB	8.2 KB
Dependencies	0	4

Use tabcoord when you need the full coordination layer.
Use broadcast-channel when you need a polyfill for old browsers or Node.js IPC.

tabcoord vs WebSocket

Feature	tabcoord	WebSocket
Setup	Zero config	Server required
Latency	< 5ms	50–200ms
Works offline	✅ Yes	❌ Needs server
Multi-user	❌ One user's tabs	✅ Many users

Use tabcoord when it's one person's tabs on one machine.
Use WebSocket when you need real-time multi-user collaboration.

How Small Is It?

Package	Gzipped	Dependencies
`tabcoord`	4.78 KB	0
`tabcoord-react`	0.9 KB	0 (peer dep: `tabcoord`, `react`)

Under 6 KB total. Nothing else gets pulled in.

Quick Summary

✅ Shared state across tabs, synced in real time
✅ Persists across page refreshes automatically
✅ Leader election — one tab handles background work
✅ Lock manager — no duplicate actions across tabs
✅ Event bus with wildcard support and replay
✅ SSR safe — works with Next.js and Remix
✅ Falls back gracefully on older browsers
✅ TypeScript first, zero dependencies

If you've ever hacked together localStorage event listeners to sync tabs and thought there has to be a better way — this is what I built for exactly that.

tabcoord on npm · tabcoord-react on npm

I Built a Tool That Saves Me 5 Minutes Every Morning

Mohamed Ismail — Fri, 12 Jun 2026 11:00:31 +0000

Every morning I open my laptop, start the backend, start the frontend, open a db tab, open a git tab. Five minutes gone before I've written a single line of code.

Why I made this

I kept writing the same batch script over and over for different projects. Every time I started something new, I'd copy an old one and mess up the paths. Half the time it wouldn't run because I forgot to escape a backslash somewhere.

So I built something to fix that.

Meet WinTerm Pilot

WinTerm Pilot is a free web tool that builds Windows Terminal launch scripts for you.

You tell it what your dev setup looks like — which folders, which commands, which tabs you need open — and it generates a .bat script you can double-click every morning. One click, everything opens exactly how you like it.

No installation. No account. Just open the site, fill in your setup, download the script, done.

How it works

Go to winterm-pilot.netlify.app.

You'll see a simple builder. Add your tabs — give each one a name, a folder path, and the command to run (like npm run dev or dotnet run). You can set which tab opens first, choose split panes if you want, and pick your shell (PowerShell, CMD, or WSL).

Hit generate. Copy or download the script. Run it.

That's it. Your whole dev environment launches in one go.

Who is this actually for?

If you work on Windows and you:

Have more than two things running when you code
Keep forgetting which folder your backend lives in
Wish your terminal just opened the way you want it

...then this is for you.

Try it

👉 winterm-pilot.netlify.app

It's free, it runs in your browser, and your data never leaves your machine. If it saves you even two minutes a day, that's over ten hours a year back in your pocket.

Built by a developer who was tired of clicking the same things every morning.

The BroadcastChannel API — The Browser Feature You've Been Ignoring

Mohamed Ismail — Tue, 09 Jun 2026 07:14:52 +0000

Most developers find this API by accident — usually while chasing a bug where the user logged out in one tab and the other three still show the dashboard. Embarrassing in dev, security issue in prod.

The fix is built into every modern browser. It's called BroadcastChannel. Most people skip it because they didn't know it was there.

What even is it?

You know how your browser can have the same website open in multiple tabs? Those tabs are completely isolated from each other — they can't talk. Open five tabs of your app and each one lives in its own little bubble.

The BroadcastChannel API fixes that. It lets any tab, window, or iframe on the same origin send a message to all the others. One line to open a channel, one line to send, one line to listen. That's it.

// Open a channel
const channel = new BroadcastChannel('my-app');

// Send a message
channel.postMessage({ type: 'hello', payload: 'world' });

// Listen in another tab
channel.onmessage = (event) => {
  console.log(event.data); // { type: 'hello', payload: 'world' }
};

No libraries. No server. No WebSockets. Just the browser doing the work for free.

01 — Sync logout across tabs

The obvious one, but worth stating. User logs out in tab A — tabs B, C, D don't know. They sit there showing an authenticated UI to nobody.

const authChannel = new BroadcastChannel('auth');

function logout() {
  clearSession();
  authChannel.postMessage({ type: 'LOGOUT' });
  window.location.href = '/login';
}

authChannel.onmessage = (e) => {
  if (e.data.type === 'LOGOUT') {
    window.location.href = '/login';
  }
};

Works both ways — broadcast login too. An idle tab can automatically refresh without the user lifting a finger.

02 — Keep UI state in sync without a round-trip

Power users open your app in two windows side by side. They update something in the left window. The right window is stale. BroadcastChannel pushes that state update to every open tab the moment it changes — no refetch, no polling.

const uiChannel = new BroadcastChannel('ui-state');

function updateTodos(newTodos) {
  setTodos(newTodos);
  uiChannel.postMessage({ type: 'TODOS_UPDATED', todos: newTodos });
}

uiChannel.onmessage = (e) => {
  if (e.data.type === 'TODOS_UPDATED') {
    setTodos(e.data.todos); // works with React, Zustand, anything
  }
};

03 — Single-tab leader election

A polling loop hitting your API every 5 seconds doesn't need to run in all 8 tabs the user has open. That's 8× the server load for zero benefit. Elect one tab as the leader, let it do the work, broadcast results to the rest.

const ch = new BroadcastChannel('leader');
let isLeader = false;
let contested = false;

ch.postMessage({ type: 'CLAIM' });

ch.onmessage = (e) => {
  if (e.data.type === 'CLAIM' && isLeader) {
    ch.postMessage({ type: 'TAKEN' }); // we're already here
  }
  if (e.data.type === 'TAKEN') {
    contested = true; // back off
  }
};

setTimeout(() => {
  if (!contested) {
    isLeader = true;
    startPolling(); // only this tab polls
  }
}, 300);

When the leader tab closes, another tab claims it after the timeout. Users never notice anything happened.

04 — Deduplicate push notifications

Push notification fires from a service worker. You have 3 tabs open. Without coordination, all 3 show the same toast. The user sees the same notification three times. Not great.

// In the service worker — broadcast the push
const ch = new BroadcastChannel('notifications');
self.addEventListener('push', (e) => {
  ch.postMessage({ type: 'PUSH', data: e.data.json() });
});

// In the app — first tab to handle it wins
let handled = false;
ch.onmessage = (e) => {
  if (e.data.type === 'PUSH' && !handled) {
    handled = true;
    showToast(e.data.data);
    setTimeout(() => { handled = false; }, 1000);
  }
};

05 — Theme and settings sync

User flips to dark mode in one tab. Every other tab should switch too — right now. Same for language, font size, accessibility preferences. Anything that should feel global.

const settingsChannel = new BroadcastChannel('user-settings');

function setTheme(theme) {
  localStorage.setItem('theme', theme);
  applyTheme(theme);
  settingsChannel.postMessage({ type: 'THEME', theme });
}

settingsChannel.onmessage = (e) => {
  if (e.data.type === 'THEME') applyTheme(e.data.theme);
};

06 — Share expensive computation results

User uploads a 50MB CSV in Tab A. Your app parses and aggregates it — takes 2 seconds. Tab B is open and needs the same data. Without coordination it parses the whole thing again from scratch. Instead, let Tab A do the work and broadcast the result.

// Tab A — does the heavy lifting
async function processAndShare(file) {
  const result = await parseHugeCSV(file);
  const ch = new BroadcastChannel('processed-data');
  ch.postMessage({ type: 'CSV_READY', data: result });
}

// Tab B — gets it for free
const ch = new BroadcastChannel('processed-data');
ch.onmessage = (e) => {
  if (e.data.type === 'CSV_READY') renderTable(e.data.data);
};

07 — Multi-tab form draft recovery

User starts filling a long form in Tab A, then opens the same route in Tab B by accident. Tab B should detect this and warn: "you have an unsaved draft open in another tab." Saves real data loss, especially in CRMs and ERPs.

const formChannel = new BroadcastChannel('form-lock');

// On mount — check if another tab already has this form open
formChannel.postMessage({ type: 'CHECK_LOCK', formId: 'invoice-42' });

formChannel.onmessage = (e) => {
  if (e.data.type === 'CHECK_LOCK' && e.data.formId === 'invoice-42') {
    formChannel.postMessage({ type: 'LOCKED', formId: 'invoice-42' });
  }
  if (e.data.type === 'LOCKED') {
    showWarning('This form is already open in another tab');
  }
};

08 — Cross-tab undo history

User makes a change in Tab A. Tab B reflects it. Then they hit undo in Tab B. Without coordination — chaos. With BroadcastChannel you can keep a shared undo stack that works across tabs, not just within one.

const historyChannel = new BroadcastChannel('undo-stack');

function pushAction(action) {
  undoStack.push(action);
  historyChannel.postMessage({ type: 'PUSH', action });
}

function undo() {
  undoStack.pop();
  historyChannel.postMessage({ type: 'UNDO' });
  rerender();
}

historyChannel.onmessage = (e) => {
  if (e.data.type === 'PUSH') undoStack.push(e.data.action);
  if (e.data.type === 'UNDO') { undoStack.pop(); rerender(); }
};

09 — Iframe-to-host communication

You're building an embedded widget or microfrontend inside an iframe. window.postMessage works but gets messy fast — origin checks, event filtering, nested frame edge cases. If the host and embed share the same origin, BroadcastChannel is cleaner. Both sides open the same channel and it just works.

// Inside the iframe
const bridge = new BroadcastChannel('widget-bridge');

bridge.postMessage({ type: 'ITEM_SELECTED', id: 42 });

bridge.onmessage = (e) => {
  if (e.data.type === 'RESET') resetWidget();
};

Three things to know before you ship

Same origin only. https://yourapp.com and https://app.yourapp.com are different origins. They cannot talk to each other through this API.

The sender doesn't receive its own message. The tab that calls postMessage won't trigger its own onmessage. If the sender also needs to react, call your update function directly alongside the broadcast.

Clean up in React. Close the channel on unmount — return () => channel.close() inside useEffect. Otherwise you'll leak listeners across re-mounts.

Browser support is all modern browsers — Chrome, Firefox, Safari, Edge, all fine. The whole API is four things: postMessage, onmessage, addEventListener, and close. Once you know it exists, you start seeing the problem it solves in almost every multi-tab web app.

How I Stop Myself From Building Bad Ideas

Mohamed Ismail — Fri, 29 May 2026 13:54:49 +0000

How I Stop Myself From Building Bad Ideas

I have a problem. I get excited about product ideas way too fast.

I'll be showering, and suddenly — bam — a billion-dollar idea. I write a PRD, open a code editor, and start building. Two weeks later, I realize nobody actually needs it.

I needed a way to kill bad ideas before I invested time in them. So I built a filter.

What It Does

It's a simple workflow. You write your PRD like you normally would, then run it through a set of prompts with any AI assistant. The AI analyzes your idea across 25 different angles — stuff like market demand, competition, pricing, risks, technical complexity, and even things like compliance and accessibility.

At the end, you get an HTML dashboard. It looks like a professional investment memo, but you get it in about 5 minutes.

What You'll See in the Dashboard

The dashboard has everything on one page:

Overall score — a number from 0 to 100 with a verdict label
Radar chart — see all your scores at a glance
SWOT grid — strengths, weaknesses, opportunities, threats
Risk register — what could kill your idea, with severity levels
Market sizing — TAM, SAM, SOM breakdown
Competitors — how you stack up against existing solutions
Feature fit — which features actually matter
Pricing suggestions — what people might pay
And a lot more — 25 analysis modules total

Everything is in one HTML file. Open it, scroll around.

Don't think this is it. This is just for the reference and it does much more analysis. clone it and surf yourself.

Why the Scores Feel Harsh

The AI is told to be honest. Brutally honest. Most ideas score below 70. That's not a bug — it's the point.

I wanted a tool that tells me the truth, not what I want to hear. If my idea scores 30, I want to know why so I can either fix it or move on.

The prompts specifically tell the AI to:

Never sugarcoat
Never invent traction or users
Be direct about flaws
Use real market assumptions, not wishful thinking

How I Use It

I write a PRD for any idea that excites me. Takes about an hour. Then I run the analysis. If the score is low and the feedback reveals problems I can't solve, I drop the idea and move to the next one.

It saves me weeks of building things nobody wants.

If the score is decent and the feedback points to fixable problems, I know exactly what to work on first.

The Project Is Open Source

Everything is on GitHub — the prompts, the HTML template, the workflow instructions. You can use it with any AI chatbot you like. No installation needed.

GitHub: github.com/ihssmaheel-dev/prd-intelligence-skill

I still get excited about ideas. I just don't build all of them anymore.

PRD Intelligence: Turn Your Product Ideas into Strategic Reports

Mohamed Ismail — Sun, 10 May 2026 19:10:44 +0000

What is PRD Intelligence?

PRD Intelligence is a tool that helps product teams analyze their ideas quickly. Just paste your Product Requirements Document (PRD) and get a complete analysis in minutes.

How it Works

You write down your product idea
The tool analyzes it using AI
You get a full report with 20 business areas covered

Key Features

20 analysis areas: Market size, competition, risks, marketing, and more
Privacy first: Your data stays on your computer
Works with any AI provider: OpenAI, Claude, and others
No signup needed: Everything works in your browser

Why It's Useful

Product planning usually takes weeks. This tool does it in minutes. Just write your idea, and get instant business analysis.

Try It Yourself

Visit PRD Intelligence to try it out.

If you have any suggestions, please comment down below!

Have a great idea? Just paste it and see what insights you get!

DEV Community: Mohamed Ismail

Why I Switched from ts-rest to oRPC

tRPC or oRPC?

What I liked about oRPC

Why I made the switch

Final thoughts

I Built a Receipt Printer for Your GitHub Year 🧾

How it works

Why a receipt?

A printer that feels like a printer

The numbers stay honest

Take it with you

Put it on your GitHub profile

Your turn 👀

Beyond the Green Squares: Turning GitHub Activity Into Things Worth Keeping

What this series is

Project #1 is live 🧾

Now I need you 👀

dep-blame: Understand How Your Dependencies Changed

What does it do?

Why is it useful?

Try it

Looking for a opportunity

I Wired the Boring 80% So You Can Build the Interesting 20%

Why I Built This

A Quick, Honest Note Before You Dive In

The Idea: Clean Modules, One Codebase

No More Surprise Crashes

Built for AI Coding Tools

What You Get Out of the Box

API, Two Ways

Multi-Tenancy, Done Right

Roles & Permissions

Solid Authentication

No Double Charges

Reliable Background Jobs

Direct-to-S3 Uploads

GDPR Ready

Realtime Updates

Shared Design Tokens & i18n

Built-In Observability

Add a New Feature in Seconds

The Stack

Get Started in 3 Minutes

Star It, Try It, Help Shape It

I Wired the Boring 80% So You Can Build the Interesting 20%

Starting is easy. Surviving is hard.

The 10-second pitch

The architecture: a modular monolith with lite DDD

A real backend, not a todo-app demo

Web + mobile, speaking the same language

The complete stack, and why each piece earned its place

The developer experience is the feature

Testing without the lecture

Built for the AI-assisted era 🤖

How it makes life simpler, concretely

It's still cooking — come help 👨‍🍳

Get the code in 2 minutes

I Built a Library to Sync Browser Tabs

Here's Why and How to Use It

What is tabcoord?

Built on Top of the Native BroadcastChannel API

Shared State Across Tabs

Only One Tab Does the Heavy Work

Preventing Race Conditions with Locks

Sending Events Across Tabs

Works with Next.js and Remix

How Does It Compare?

tabcoord vs Native BroadcastChannel

tabcoord vs broadcast-channel (2k stars, 3M+ weekly downloads)

tabcoord vs WebSocket

How Small Is It?

Quick Summary

I Built a Tool That Saves Me 5 Minutes Every Morning

Why I made this

Meet WinTerm Pilot

How it works

Who is this actually for?

Try it

The BroadcastChannel API — The Browser Feature You've Been Ignoring

tabcoord vs `broadcast-channel` (2k stars, 3M+ weekly downloads)