DEV Community: Yaseen Khatib

My Networking Runs Itself: A LinkedIn Pipeline

Yaseen Khatib — Wed, 04 Nov 2026 12:25:13 +0000

[ EXECUTIVE TEARDOWN // TL;DR ]

Consistency is a systems property: a cron-driven GitHub Actions pipeline publishes to LinkedIn and commits its own state ledger back to Git.
The human trust boundary is the queue — the machine automates showing up, never the judgment about what carries my name.
The pipeline kept publishing through heads-down building weeks, so recruiter conversations arrived on its schedule, not my energy level's.
The same queue → scheduled worker → auditable state pattern automates any valuable-but-skipped work inside a company, in days.

Networking is a numbers game played with hours you don't have. Writing a good LinkedIn post takes an evening; doing it consistently takes a discipline that competes with actually building things. So I treated my own visibility as an engineering problem and shipped a product for it: an autonomous pipeline that turns my real work into scheduled LinkedIn content, publishes it, and tracks its own state — entirely on free infrastructure. My network started growing while I slept.

How do you automate LinkedIn content for $0?

The system is deliberately boring, which is the point. A GitHub Actions workflow wakes on a cron schedule. It reads a content queue, generates the post draft from the queued topic, publishes to LinkedIn, and then — the part most automation skips — commits its own state back to the repository in a published.json ledger. The Git history is the database. There is no server to babysit, no dashboard subscription, no runtime cost. If it ever misfires, the ledger is a diff I can read and revert like any other commit.

Automation with a quality gate

The word "bot" earns its bad reputation from systems that publish without judgment. Mine has a human trust boundary in the same place all my products do: the queue. Nothing enters it that I haven't decided is worth saying — the pipeline automates the showing up, not the thinking. It is the same propose/confirm split that governs my finance agent: the machine handles cadence and delivery, the human owns the content decisions that carry my name.

Consistency is a systems property, not a personality trait. If showing up matters and humans are bad at it, that is not a self-improvement problem — that is a pipeline waiting to be built.

What it changed

The pipeline did what consistency always does: compounded. Posts went out on schedule through weeks when I was heads-down shipping Sable and streamerOS — precisely the weeks I would previously have gone silent. Profile visits, connection requests, and recruiter conversations arrived on the pipeline's schedule instead of my energy level's. The product's full architecture breakdown lives on its product page.

The transferable lesson for companies

Every company has a version of this problem: work that is valuable, repetitive, and chronically skipped because it competes with "real" work — release notes, changelogs, status updates, onboarding emails, documentation refreshes. The pattern that fixed my networking fixes those too: a queue a human curates, a scheduled worker that executes, state committed somewhere auditable, and zero new infrastructure to own. I've now built that pattern three times (content, outreach, and blog publishing) — it takes days, not quarters, and it never calls in sick.

~/keep-reading

Yaseen Khatib · MERN + AI Architect

Ships autonomous AI products solo — five in the last twelve months. More about Yaseen →

Want this built for your business?

I build what this post describes for clients — RAG chatbots on your own documents, AI added to systems you already run, custom software — at fixed prices you see before we start. Hiring instead? I'm open to senior and lead roles.

See services and prices →I'm hiring

Originally published at yk.streamerosai.com/blog/linkedin-pipeline-job-search-runs-itself/.

Originally published on my portfolio.

WebSocket Telemetry at Scale

Yaseen Khatib — Wed, 04 Nov 2026 12:25:12 +0000

[ EXECUTIVE TEARDOWN // TL;DR ]

In-memory broadcast only reaches the local process — multi-instance real-time needs a shared backplane (Redis pub/sub).
Scope subscriptions into rooms so each client receives only the streams it watches, collapsing bandwidth and CPU.
Coalesce high-frequency sources on the server to a renderable frame rate before broadcasting.
Handle backpressure at the source, not after it has already flooded the client.

A single WebSocket server streaming telemetry to a few clients is a weekend project. Feeding thousands across multiple instances is systems work. I learned that on streamerOS: the “one process holds every socket” sketch sailed on one pod and face-planted the moment we scaled out. Each instance owns its own connection table, so A cannot fan out to subscribers that landed on B; broadcasts die at the process boundary and your graphs freeze.

The horizontal-scaling problem

Once you run more than one server process behind a load balancer, connections fan out across instances. An event that originates on one instance has to reach subscribers on all of them. In-memory broadcast only reaches the local process; you need a shared backplane so every instance hears every event. In the pattern I call Trinity Architecture, this cross-instance fanout lives in the orchestration tier — the UI stays dumb, render-only, and the adapter keeps payloads lean. I use a Serialization Adapter there too; on IntegrateX it stripped non-essential React Flow UI metadata before persistence and cut graph payloads 94%, and the same habit keeps telemetry frames tight.

scale.ts

// Redis pub/sub backplane → broadcast across every instance
import { createAdapter } from "@socket.io/redis-adapter";

io.adapter(createAdapter(pubClient, subClient));

// emit anywhere; every instance's subscribers receive it
metrics.on("tick", (m) => io.to("telemetry").emit("metric", m));

Rooms, not broadcasts

Do not push every metric to every client. Scope subscriptions into rooms — per dashboard, per device, per tenant — so a client receives only the streams it is watching. This collapses bandwidth and CPU from O(clients × events) toward O(interested clients), which is the difference between a system that scales and one that melts at a few thousand connections. On streamerOS, moving from a global channel to roomed feeds stopped NIC spikes, trimmed CPU interrupts, and cut render thrash when operators flipped between views; the UI joined/left rooms via the orchestrator in my Trinity split, never from components.

Coalesce at the source

High-frequency sources emit faster than any client can render or any socket should carry. Sample or debounce on the server to a sane frame rate before broadcasting, so you push the latest truth at a rate the wire and the React reconciler can actually absorb. Budget is ~16ms at 60fps; a 200 Hz stream will starve the UI thread. Track last-value-wins per key and pre-aggregate counters server-side. Backpressure handled at the source beats backpressure discovered at the client.

Scaling real-time is not about a faster socket. It is about making sure each event travels exactly as far as it needs to — and no further.

For the single-server fundamentals and the React consumption side, see Real-Time Telemetry; the live systems are streamerOS and the CMZ portal. The instinct I bring to a team is deciding how far each event should travel before you scale out, not after the graphs freeze.

~/keep-reading

Yaseen Khatib · MERN + AI Architect

Ships autonomous AI products solo — five in the last twelve months. More about Yaseen →

Want this built for your business?

See services and prices →I'm hiring

Originally published at yk.streamerosai.com/blog/websocket-telemetry-at-scale/.

Originally published on my portfolio.

MERN Stack Developer vs Full Stack Developer: What Changes

Yaseen Khatib — Fri, 30 Oct 2026 10:59:52 +0000

[ EXECUTIVE TEARDOWN // TL;DR ]

A MERN stack developer is a full-stack developer who works in MongoDB, Express, React and Node; full stack is the range, MERN is one choice of tools.
MERN fixes one language end to end, a document database by default, and a single npm ecosystem, which is why it suits small teams and real-time products.
The titles diverge on relational database experience, real-time work, and server rendering; test for those rather than the acronym.
Hire a MERN developer when the product is already MERN; hire a broader full-stack developer when the stack is still a choice.

A MERN stack developer is a full-stack developer who has chosen one specific set of tools: MongoDB for the database, Express for the server, React for the interface, and Node.js for the runtime. Every MERN developer is a full-stack developer. Not every full-stack developer works in MERN. That is the whole relationship, and the rest of this post is about what the choice means when you are hiring one or deciding to become one.

What "full stack" actually covers

Full stack means one person can take a feature from the database schema to the pixels on screen and the deployment in between. The stack itself is open. A full-stack developer might work in Django and Vue, Rails and Hotwire, Laravel and Blade, Spring and Angular, or Next.js and Postgres. What makes them full stack is the range, not the tools.

In practice the title hides a spread. Some full-stack developers are backend engineers who can write enough React to ship a form. Others are front-end specialists who can stand up an API. The useful question in an interview is never "are you full stack" but "which half would you reach for first, and how far does the other half go."

What MERN narrows down

MERN fixes every layer to JavaScript or TypeScript. That has three consequences that matter more than the acronym.

One language end to end. The same types, the same validation logic and often the same utility code run in the browser and on the server. On a small team that removes a whole category of mismatch bugs between what the API sends and what the UI expects.
A document database by default. MongoDB stores JSON shaped documents, which maps cleanly onto the objects a React app already handles. It also means schema discipline is on the developer, not the database. Aggregation pipelines and index design become the performance work, as I covered in optimising MongoDB aggregation.
A single ecosystem. npm, the Node event loop, Express middleware and React's component model are one world. A MERN developer goes deep in it rather than wide across several.

Where the two titles diverge in real work

The difference shows up in three places.

Databases. A general full-stack developer usually has relational experience: joins, transactions, migrations, constraints enforced by the database. A MERN developer who has only worked with MongoDB may not. The reverse is also true: relational-first developers often model documents badly, embedding what should be referenced and referencing what should be embedded.

Real-time and streaming. Node's event loop makes WebSockets and streaming responses natural, which is why a lot of real-time product work ends up in MERN shops. I wrote up the pattern in WebSocket telemetry at scale. A full-stack developer from a request-response framework has to learn that model rather than inherit it.

Rendering. Plain MERN is a client-rendered React app talking to an Express API. Modern full-stack JavaScript work has largely moved to frameworks like Next.js that render on the server or at build time, which changes how data loading, caching and SEO work. Many MERN developers have made that move; the acronym has not caught up.

Which one to hire

Hire for the problem, then check the stack.

If your product is already in MongoDB, Express, React and Node, hire a MERN developer and test depth: schema design, aggregation, authentication, and how they structure a React app once it has more than twenty components.
If you are choosing a stack, hire a full-stack developer who has shipped in more than one and ask them to argue against MERN. The honest answer sometimes is Postgres.
If the work involves AI features, the stack matters less than whether the person has put a model into production behind a real interface: retrieval, evaluation, cost control, and the boundary between what the model proposes and what the system commits. My own path went MERN first and then into that, which I described in from web developer to AI engineer.

Which one to become

Start with MERN or any single coherent stack, because depth in one place teaches you what the layers are for. Then deliberately break the acronym: learn a relational database, learn a server-rendering framework, and ship something with a model in it. At that point the title on your CV is full-stack developer, and MERN is the first line under it rather than the whole story.

If you are hiring for either, the hire page describes what I build and how I work.

~/keep-reading

Yaseen Khatib · Full-Stack AI Engineer

Ships autonomous AI products solo — five in the last twelve months. More about Yaseen →

Want this built for your business?

See services and prices →I'm hiring

Originally published at yaseenkhatib.streamerosai.com/blog/mern-stack-developer-vs-full-stack-developer/.

AI Engineer Portfolio Examples: What Reviewers Verify

Yaseen Khatib — Fri, 30 Oct 2026 10:59:48 +0000

[ EXECUTIVE TEARDOWN // TL;DR ]

Reviewers check whether anything runs, whether you made the hard decisions, whether you can explain a trade-off, and whether anything is measured.
The strongest piece is a live retrieval assistant on the portfolio itself, with a visible refusal path and its index exposed as an MCP server.
A product with a readable trust boundary, such as a propose-and-confirm agent, gives reviewers something to disagree with, which is the point.
Include one measured before-and-after result and one plainly told failure; both raise credibility more than another success.

An AI engineer portfolio has one job: let a stranger verify, in a few minutes and without talking to you, that you have put a model into production and understood what happened. Most portfolios fail that test not because the work is weak but because the site shows a list of technologies instead of a system someone can inspect. This post is the checklist I used to build mine, with this site as the worked example, including the parts I got wrong.

What a hiring manager is actually checking

Nobody reading an AI engineer portfolio is impressed by the words RAG, agents or fine-tuning any more. They are looking for four things, in roughly this order.

Does anything here run? A live system beats a screenshot, and a screenshot beats a bullet point.
Did you make the hard decisions, or follow a tutorial? Retrieval thresholds, refusal behaviour, cost controls, the boundary between what the model proposes and what the system commits.
Can you explain a trade-off in writing? One honest paragraph about a failure is worth more than ten about a success.
Is any of it measured? Latency, cost per request, eval scores, a payload reduction with a before and after.

Example 1: a live, grounded assistant on the site itself

The strongest example an AI engineer can put on a portfolio is a retrieval system that answers questions about the portfolio. It is self-demonstrating: the visitor asks, the system cites its source, and when asked something the site does not cover, it refuses instead of guessing.

On this site that is the concierge on the home page. It runs on a Cloudflare Worker, embeds the question with Workers AI, retrieves from a Vectorize index built from the site's own content, and declines below a confidence threshold. The same index is exposed as an MCP server, so a reviewer can connect it from inside Claude and interrogate it there. The design decisions are written up in semantic caching for edge RAG and the pipeline is re-indexed automatically after every deploy.

What makes it a portfolio piece rather than a widget is that the refusal path is visible. Ask it something it cannot know and watch it say so. That one behaviour answers the "did you follow a tutorial" question.

Example 2: a product with a trust boundary you can read

The second example is a shipped product where the AI can do damage if it is wrong, and the architecture stops it. For me that is Sable, a local-first finance agent. Every record lives in on-device SQLite with no cloud backend, and every action the model wants to take is rendered as a review card a person confirms. A hallucination's blast radius is one dismissed card.

The portfolio piece is not the app. It is the write-up of why the model never touches money. A reviewer can disagree with the design, and that is the point: it gives them something to disagree with.

Example 3: a measured engineering result

Every AI engineer portfolio should contain at least one number that was measured rather than estimated, with the before and the after. Mine is a 94% payload reduction on a workflow engine's graph serialisation. It is not an AI result. It is there because it shows the habit of measuring, which is the same habit that makes LLM cost control and evals possible. The FinOps side of that habit is in the AI FinOps playbook.

Example 4: the operating model, written down

Senior roles are increasingly about how you work with AI tools, not only how you build AI products. A portfolio can show that directly: a description of the workflow, what is automated, what is reviewed, and what the constitution files say. Mine is in one architect, Claude Code and MCP, with a 30-day plan a team could copy. Pipelines on this site, such as the weekly AI-drafted post that opens a pull request for review rather than publishing, are that model running in public.

What I got wrong, which is also an example

For four months this site was invisible to Google because an entrance animation shipped its hidden state into the static HTML, so the crawler's snapshot was blank. A separate mistake before that was an auto-publishing pipeline that flooded the site with commodity explainer posts, which got the whole site treated as low value. Both are documented in the repository and both are on this page on purpose. An AI engineer portfolio that admits what broke is more credible than one that does not, because every reviewer knows something broke.

A checklist you can apply to your own

One live system a visitor can poke, with a visible refusal or guardrail.
One product where the AI could do harm and the architecture prevents it, with the reasoning written down.
One measured result with a before and after, even if it is not about AI.
One description of how you work with AI tools, specific enough to copy.
One failure, told plainly.
Source code or a repository link for at least one of the above.
No fabricated metrics, testimonials or dates. Reviewers check.

Templates and themes do not matter much. The list above does. If you would rather see the whole thing applied, the projects page is the index and the hire page is where it leads.

~/keep-reading

Yaseen Khatib · Full-Stack AI Engineer

Ships autonomous AI products solo — five in the last twelve months. More about Yaseen →

Want this built for your business?

See services and prices →I'm hiring

Originally published at yaseenkhatib.streamerosai.com/blog/ai-engineer-portfolio-examples/.

WhatsApp Chatbot for Business: Monthly SaaS vs Owning It

Yaseen Khatib — Sat, 24 Oct 2026 09:01:42 +0000

[ EXECUTIVE TEARDOWN // TL;DR ]

Every WhatsApp chatbot pays Meta per delivered message; service replies to customers who wrote first include 1,000 free a month per number from 1 October 2026.
Subscription platforms add a plan fee and often a per-message markup; an AI add-on can roughly double the plan fee.
Over three years, plan fees for an AI-answering setup run to around ₹1.9–2.1 lakh before GST on the plans compared here; a one-time build costs about one year of that.
Rent for broadcasts, team inbox and menu bots; own the bot when it must answer from your documents, refuse rather than guess, or act on your systems.

Short answer: rent a WhatsApp chatbot platform if what you need is broadcasts, a shared team inbox and menu-style flows. Own the bot if it has to answer questions from your own documents or act on your own systems. Either way you pay Meta for messages. The decision is about what you pay on top of that, every month, for as long as the bot runs.

Every page that ranks for “WhatsApp chatbot” in India is written by a company selling a subscription to one, so none of them works through the comparison below. I build these, so I have a bias too. I have tried to make it visible by saying where renting is the better call. All prices were checked on the vendors' own pricing pages on 23 October 2026, and they change, so check them again before you sign anything.

The cost nobody avoids: Meta's per-message fees

A real WhatsApp chatbot runs on the WhatsApp Business Platform (the API), not the free WhatsApp Business app. Since 1 July 2025 Meta charges per delivered message, priced by category and by the recipient's country. Indian businesses can now be billed in rupees, and Meta requires accounts billed in India to move to INR by 31 December 2026.

Marketing templates (offers, broadcasts) are the expensive category, a little under a rupee each on Meta's INR rate card.
Utility (order updates) and authentication (OTPs) cost a fraction of that.
Service messages, your replies when a customer writes to you first, are what a support chatbot mostly sends. From 1 October 2026 each business number gets 1,000 free service messages a month, and the 1,001st is charged.
Conversations that start from a Click-to-WhatsApp ad open a free window of up to seven days.

A bot that mainly answers incoming questions sits largely inside the cheap or free categories. A bot that mainly sends promotions does not, and no platform choice changes that.

What the subscription platforms add

Platforms such as WATI and Interakt are Business Solution Providers: they connect you to the API and give you a dashboard. You pay a plan fee, and on top of Meta's rate, often a per-message markup.

Platform and plan

Plan fee (INR, + GST)

AI that answers questions

WATI Growth

₹2,699 / month, billed quarterly

1 AI agent, 2,000 AI credits

WATI Pro

₹5,799 / month, billed quarterly

2 AI agents, 5,000 AI credits

WATI Business

₹16,799 / month, billed quarterly

Unlimited agents, 20,000 AI credits

Interakt Growth

₹2,799 / month

Add-on: WhatsApp AI Agents, ₹2,499 / month for 100 AI messages, then ₹0.50 each

Interakt Advanced

₹3,799 / month

Same add-on

The markup is easiest to see on Interakt, which publishes its per-message rates: a service message is ₹0.128 on Growth, against ₹0.115, the utility and authentication rate on Meta's INR rate card for India. Only Interakt's Enterprise plan says it has no markup. WATI's page says per-message charges vary by category and links its rate card separately.

None of this is a scandal. A team inbox, a broadcast scheduler, template management and a Shopify connector are real software, and building them yourself would cost far more than the subscription.

Three years of each, worked through

An illustration, not a client: a business that wants an AI assistant answering customer questions on WhatsApp, with a couple of staff handing over to a person when the bot cannot help. Plan fees only, before GST and before Meta's charges, which are the same in every column.

Interakt Growth + AI Agents

WATI Pro

Owned build

Per month

₹5,298, plus ₹0.50 per AI message after 100

₹5,799

Hosting and model usage only

36 months of plan fees

₹1,90,728

₹2,08,764

none

Up front

none

the build, from $800 at my published price

At current exchange rates the build costs about what one year of either plan does, so the owned bot breaks even around the end of the first year and is ahead from then on. The Interakt column is also the optimistic one: 100 AI messages a month is a few a day, so any real volume adds the per-message AI charge on top. An owned bot's model usage depends on your volume and the model you choose; for short answers grounded in a few documents it is small, and it can be estimated before you commit.

When renting is the right answer

If the job is broadcasts to a customer list, abandoned-cart reminders from Shopify, catalogues and a shared inbox for five people, rent a platform. That is exactly what they are built for, it works on day one, and building it yourself would be paying to recreate a product that already exists. The same goes for a menu bot (press 1 for timings, 2 for location) with no AI in it.

Renting also wins if nobody in the business will own a piece of software. An owned bot needs someone, in-house or hired, to keep the WhatsApp app credentials valid, update the documents it answers from, and fix it when Meta changes something.

When owning it is the right answer

It must answer from your documents. Policies, product manuals, fee structures, a price list that changes monthly. This is retrieval-augmented generation (RAG): the bot looks up the relevant passages and answers only from them.
It must refuse rather than guess. When nothing relevant is found above a similarity threshold, a well-built bot says it does not know and hands over to a person. A generic AI agent tuned for engagement will often improvise.
It must touch your systems. Look up an order in your own database, book a slot in your own calendar, write a lead into your own CRM.
You want the data. The conversations and the customer records live in a database you own, not in a vendor's dashboard you export from.

What an owned WhatsApp chatbot actually is

Less than people expect. Meta's Cloud API sends every incoming message to a webhook you host. Your code verifies it, retrieves the relevant passages, asks a model for an answer grounded in them, and posts the reply back to the Graph API. A minimal handler:

webhook.ts

// 1. Meta verifies the webhook once with a GET request.
if (req.method === "GET") {
  const ok = url.searchParams.get("hub.verify_token") === env.VERIFY_TOKEN;
  return new Response(ok ? url.searchParams.get("hub.challenge") : "forbidden",
                      { status: ok ? 200 : 403 });
}

// 2. Every customer message arrives as a POST.
const msg = body.entry?.[0]?.changes?.[0]?.value?.messages?.[0];
if (msg?.type === "text") {
  const passages = await retrieve(msg.text.body);        // vector search
  const answer = passages.length
    ? await answerFrom(passages, msg.text.body)          // grounded reply
    : "I don't have that in our documents. A person will reply shortly.";

  await fetch(GRAPH_URL + "/" + env.PHONE_NUMBER_ID + "/messages", {
    method: "POST",
    headers: { Authorization: "Bearer " + env.WA_TOKEN,
               "Content-Type": "application/json" },
    body: JSON.stringify({ messaging_product: "whatsapp", to: msg.from,
                           type: "text", text: { body: answer } }),
  });
}

The reply goes out inside the 24-hour window the customer opened, so it is a service message. The real work sits in retrieve and answerFrom: splitting documents sensibly, choosing the threshold, and checking that answers cite what they used. That is also where most cheap chatbots cut corners.

Two things this does not remove. Outbound messages outside that window still need templates approved by Meta, owned bot or not. And your number still needs a verified Meta Business account, which takes paperwork rather than code.

A quick way to decide

Write down the ten questions customers ask most. If a menu answers them, rent a platform or use the free app's quick replies.
If the answers live in documents that change, or need a lookup in your systems, you need RAG and probably an owned bot.
Multiply the platform's plan plus its AI add-on by 36 and set that next to a one-time build plus its running cost.
Decide who maintains it. If the answer is nobody, rent.

If the answer points to owning it, the AI chatbot page has my fixed prices and a live assistant on this site built the same way, which you can try before deciding anything.

~/keep-reading

Yaseen Khatib · Full-Stack AI Engineer

Ships autonomous AI products solo — five in the last twelve months. More about Yaseen →

Want this built for your business?

See services and prices →I'm hiring

Originally published at yaseenkhatib.streamerosai.com/blog/whatsapp-chatbot-saas-vs-owning-it/.

Real-Time Telemetry: Why Polling Lies, and WebSockets Don't

Yaseen Khatib — Wed, 23 Sep 2026 09:27:45 +0000

[ EXECUTIVE TEARDOWN // TL;DR ]

Polling can't be both fresh and cheap; a push model has the server speak only when state actually changes.
Broadcast events over a persistent socket and map them onto React state with a thin subscription.
Coalesce high-frequency sources on the server to a renderable frame rate, and isolate live state so only affected components repaint.
Single-source-of-truth sync — every client identical in the same instant — is what eliminates a whole class of stale-data errors.

After shipping enough "live" dashboards — including the real-time layer of the CMZ portal — one truth stuck: a polling dashboard is lying most of the time. Between ticks, operators act on stale numbers; shrink the window and you DoS your own APIs with empty work. For telemetry — CPU, chat velocity, scene state — stop interrogating the server and let it speak. WebSockets push changes the instant they occur, giving every client the same value in the same frame.

Why polling fails at scale

Polling forces a bad trade: either ship latency or ship waste. At 5s, your UI is up to 5s wrong and your fleet fires a wall of redundant reads. At 500ms, you approach freshness while torching CPU, caches, and rate limits with "nothing changed" responses. There isn't a magic interval; the question itself is expensive. Flip the model so the server only emits when state actually mutates.

The push architecture

The backend owns an event stream and broadcasts to subscribers over a persistent socket. No request fan-out, no timers — a value flips, the server emits, every dashboard updates in the same frame. In the pattern I call Trinity Architecture, the socket handler lives in the Reactive State / Orchestration layer, the Presentation layer just renders from state and dispatches intents, and a thin Data / Serialization Adapter shapes wire events into the in-memory model. No layer talks past its neighbor, which keeps both payloads and coupling under control.

telemetry.ts

// server: broadcast on change, not on request
metrics.on("tick", (m) => io.emit("telemetry", m));

// client: subscribe once, render on push
useEffect(() => {
  const s = socket(URL);
  s.on("telemetry", setMetrics);
  return () => s.close();
}</span>, []);

Throttle the wire, not the truth

A telemetry source can fire hundreds of events per second. Humans can't read that, and React can't reconcile that without jank. Shape the firehose at the edge — sample or debounce to a renderable cadence before broadcast — so the feed is truthful but frame-friendly. On streamerOS we had to respect 60fps while chat and system metrics spiked; coalescing server-side kept backpressure off the socket and the main thread, without lying about the latest value.

Consuming streams in React without thrashing

The foot-gun is wiring "telemetry" to setState and letting it reflow the whole tree each packet. Keep hot values in a small, focused store and subscribe only the components that care. I use a Trinity split: Presentation renders from selectors; the orchestrator (Zustand or an event bus) owns the source of truth and optimistic merges; the adapter translates over-the-wire shapes into minimal, denormalized state. A CPU tick should repaint one gauge, not your navbar, tables, and modals.

Why this kills manual errors

When every client observes the same state at the same moment, an entire class of "acted on stale data" mistakes disappears. No operator is reconciling conflicting numbers; no action races a 3s-old snapshot. The win isn't speed for its own sake — it's a single, timely source of truth that every operator shares, so decisions stop diverging.

Polling asks "has it changed?" a thousand times a minute. Push answers once, the moment it does. At scale, that's the line between "live" and "laggy."

This is the live-data backbone of streamerOS and the real-time sync layer in the CMZ portal — the same playbook I reach for when correctness, smoothness, and cost need to coexist. Deciding when a system should push instead of being asked is the kind of judgment I bring to a team.

~/keep-reading

Yaseen Khatib · MERN + AI Architect

Ships autonomous AI products solo — five in the last twelve months. More about Yaseen →

Need an engineer who can build this?

I'm Yaseen Khatib — a Senior Full-Stack AI Engineer (MERN + TypeScript) who ships production AI systems solo. Open to senior and lead roles, remote or on-site.

Get in touch →See what I've shipped

Originally published at yaseenkhatib.streamerosai.com/blog/real-time-telemetry-websockets-react/.

Zero-Account Auth: Device-Bound Identity + Capability Tokens

Yaseen Khatib — Wed, 23 Sep 2026 01:56:03 +0000

Why “zero-account” and what problem does it solve?

In a zero-account model, the device is the principal. It generates a key pair and the public key, or its thumbprint, is the identity you use everywhere. Authorization comes from signed capability tokens that spell out what the device is allowed to do.

You get rid of passwords and most PII. You also remove the central auth server from the hot path. The result still has strong, auditable security properties.

How do you authenticate devices without an auth server?

Use proof-of-possession. Each device creates a non-extractable key pair locally. Every request carries two artifacts: a DPoP proof (a signed JWT with the HTTP method, target URL, and a fresh jti) and a capability token tied to that key. Resource servers verify the DPoP and check that the capability’s confirmation claim matches the device key thumbprint. No central login step is required.

Core pieces

Device key pair (identity): P-256 or Ed25519, with the private key held in a platform keystore or as a non-extractable WebCrypto key.
DPoP proof per request: a signed JWT carrying htm/htu/iat/jti to stop replay and bind requests to the device key.
Capability token: a signed, scoped token (for example, PASETO v4.public) that encodes allowed actions and lifetime.
Stateless verification: services keep the signer’s public key and a small jti replay cache instead of a user database.

How do capability tokens replace user accounts?

Put permissions, resource scopes, rate or usage limits, and expiration into a signed token. Bind it to the device key with a confirmation (cnf) claim. Services only need the issuer’s public key to verify and authorize a request. No per-user record, session, or cookie jar.

Token shape (recommended)

Format: PASETO v4.public (Ed25519) or Macaroons for attenuation/delegation chains.
Claims:
- sub: device identifier (e.g., JWK thumbprint)
- cnf: { jkt: base64url(thumbprint) } to bind token to device key
- cap: list of capabilities [{ act, res, limit?, nbf?, exp? }]
- iat/exp/jti: temporal and anti-replay metadata

Example capability list:

act=read, res=/notes/*
act=write, res=/notes/{noteId}
limit=100 writes/24h (enforced server-side by metering on jti or sub)

Bootstrapping without accounts

You still need an initial trust handshake, but not a login.

Local-first: app generates a key pair on first run and displays a pairing code. A one-shot provisioning endpoint mints the first capability (for example, from a purchase receipt, license, or admin console) scoped to the device’s jkt.
Recurring: the device refreshes capabilities using a narrow “refresh” capability, still bound to the device. No username or password, no session cookies.

Client: device key generation and DPoP

Generate a non-extractable key and make DPoP-bound API calls. In a browser, use WebCrypto. In native apps, use Keychain/Keystore.

// browser-client.ts
import { exportJWK, calculateJwkThumbprint, SignJWT } from 'jose';

// 1) Generate a non-extractable ES256 keypair and persist via IndexedDB (omitted for brevity)
const { publicKey, privateKey } = await crypto.subtle.generateKey(
  { name: 'ECDSA', namedCurve: 'P-256' },
  false, // non-extractable private key
  ['sign', 'verify']
);

const pubJwk = await exportJWK(publicKey as CryptoKey);
const jkt = await calculateJwkThumbprint(pubJwk, 'sha256');

// 2) DPoP signer
async function dpopProof(method: string, url: string) {
  return await new SignJWT({ htm: method, htu: url, jti: crypto.randomUUID() })
    .setProtectedHeader({ typ: 'dpop+jwt', alg: 'ES256', jwk: pubJwk })
    .setIssuedAt()
    .sign(privateKey as CryptoKey);
}

// 3) Call API with capability token bound to this key
export async function callApi(capToken: string, method: string, url: string, body?: any) {
  const proof = await dpopProof(method, url);
  const res = await fetch(url, {
    method,
    headers: {
      'Authorization': `Bearer ${capToken}`,
      'DPoP': proof,
      'Content-Type': 'application/json'
    },
    body: body ? JSON.stringify(body) : undefined
  });
  if (!res.ok) throw new Error(`HTTP ${res.status}`);
  return res.json();
}

Notes

The privateKey is non-extractable, so page malware can’t lift it.
DPoP carries htm/htu/jti/iat; a replay to a different URL or method fails.
capToken is issued out of band (provisioning or refresh) and must include cnf.jkt = jkt.

Server: verifying DPoP and PASETO capabilities

The resource server runs two separate checks: DPoP validity with replay protection, then capability verification and scope enforcement.

// server-auth.ts
import { decodeProtectedHeader, importJWK, jwtVerify, calculateJwkThumbprint } from 'jose';
import { V4 } from 'paseto';
import express from 'express';
import Redis from 'ioredis';

const app = express();
app.use(express.json());

// PASETO issuer keys (provisioned at deploy time)
// In production, load from HSM or env and rotate.
const { secretKey, publicKey } = await V4.generateKey('public');

const redis = new Redis(process.env.REDIS_URL!);

// Authorization middleware
app.use(async (req, res, next) => {
  try {
    const dpop = req.header('DPoP');
    const auth = req.header('Authorization');
    if (!dpop || !auth?.startsWith('Bearer ')) return res.status(401).end();
    const capToken = auth.slice('Bearer '.length);

    // 1) Verify DPoP proof
    const hdr = decodeProtectedHeader(dpop);
    if (hdr.typ !== 'dpop+jwt' || !hdr.jwk) return res.status(401).end();
    const dpopKey = await importJWK(hdr.jwk as any, hdr.alg as any);
    const { payload } = await jwtVerify(dpop, dpopKey, {
      typ: 'dpop+jwt',
      clockTolerance: '5s'
    });

    const method = (payload.htm as string || '').toUpperCase();
    const url = payload.htu as string;
    if (method !== req.method.toUpperCase()) return res.status(401).end();
    const expectedUrl = `${req.protocol}://${req.get('host')}${req.originalUrl}`;
    if (!url || !expectedUrl.startsWith(url)) return res.status(401).end();

    // Anti-replay: store jti with short TTL
    const jti = payload.jti as string;
    if (!jti) return res.status(401).end();
    const replay = await redis.setnx(`dpop:jti:${jti}`, '1');
    if (!replay) return res.status(401).send('replay');
    await redis.expire(`dpop:jti:${jti}`, 10); // seconds window

    const jkt = await calculateJwkThumbprint(hdr.jwk as any, 'sha256');

    // 2) Verify capability token (PASETO v4.public)
    const cap = await V4.verify(capToken, publicKey);

    // cnf binding check
    if (!cap.cnf || cap.cnf.jkt !== jkt) return res.status(401).send('key mismatch');

    // Temporal checks (paseto verifies exp/nbf if present, still validate policy)
    if (cap.exp && Date.now() / 1000 >= cap.exp) return res.status(401).send('expired');

    // Scope enforcement
    if (!allows(cap.cap, req.method, req.path)) return res.status(403).send('forbidden');

    // Optional: per-capability metering (rate/limit)
    // await enforceLimits(cap.sub, cap.jti, cap.cap)

    // Attach identity to request
    (req as any).device = { sub: cap.sub, jkt };
    next();
  } catch (e) {
    console.error(e);
    res.status(401).end();
  }
});

function allows(caps: any[], method: string, path: string) {
  // Minimal example: method+path prefix match
  return (caps || []).some(c =>
    (!c.act || c.act.toUpperCase() === method.toUpperCase()) &&
    pathMatch(c.res, path)
  );
}

function pathMatch(pattern: string, path: string) {
  // naive: '/notes/*' => prefix match
  if (!pattern) return false;
  if (pattern.endsWith('/*')) return path.startsWith(pattern.slice(0, -1));
  return pattern === path;
}

app.get('/notes/*', (req, res) => {
  res.json({ ok: true, device: (req as any).device });
});

app.listen(3000);

Key points

The DPoP header carries the public JWK; the server verifies it and computes the thumbprint.
Capability verification is stateless, only the publicKey is required.
cnf.jkt binds the token to the device, so a stolen token is useless without the private key.

Issuing capability tokens (no auth server required)

Any internal service holding the signing key can mint capabilities. Do it during provisioning, purchase validation, or admin workflows.

// issuer.ts
import { V4 } from 'paseto';
import { randomUUID } from 'crypto';

export async function issueCapability(secretKey: any, deviceJkt: string, caps: any[], ttlSec = 3600) {
  const now = Math.floor(Date.now() / 1000);
  const payload = {
    sub: `device:${deviceJkt}`,
    cnf: { jkt: deviceJkt },
    cap: caps,
    iat: now,
    exp: now + ttlSec,
    jti: randomUUID(),
    iss: 'cap-issuer:v1',
    aud: 'api'
  };
  return await V4.sign(payload, secretKey);
}

// Example cap set: read-only notes
await issueCapability(secretKey, 'kQ2…thumbprint…', [
  { act: 'GET', res: '/notes/*' }
], 900);

How do you revoke a leaked capability token without a DB?

Favor lifecycle controls over stateful revocation. Issue short-lived tokens, bind them to device keys with cnf.jkt plus DPoP, rotate signing keys on a schedule, and keep a small jti denylist only for emergencies. For long-lived tokens, include a refresh capability you can cut off by rotating a signer or revoking a cohort.

Practical revocation strategies

Short TTLs everywhere (5–15 minutes typical; seconds for high-value actions).
Rotate issuer keys regularly; invalidate cohorts by key ID (kid) rollover.
Maintain a Redis-backed jti denylist only for incident response; TTL entries to auto-expire.
Attenuate via nested capabilities or macaroons for delegations; revoke by refusing to mint downstream.

Macaroons vs PASETO

Aspect	PASETO v4.public	Macaroons
Simplicity	Single signature, flat claims	Attenuation via chained caveats
Delegation	Explicit via minting new token	Natural via third-party caveats
Verification	Public key verify	Shared root key + caveat verify
Fit here	Great for stateless caps	Great for delegation-heavy flows

For most zero-account APIs, PASETO v4.public with cnf binding and DPoP keeps things simple and robust. Use macaroons when you need on-chain attenuation and delegation proofs across services.

Threat model and mitigations

Token theft: mitigated by cnf.jkt plus DPoP; proofs are replay-protected by a jti cache and htm/htu binding.
Device compromise: out of scope; reduce blast radius with least-privilege capabilities and short TTLs.
Phishing: no passwords or sessions, which sharply reduces impact.
MITM: require HTTPS and HSTS; DPoP helps spot target URL tampering.
Key exfiltration (browser): make the private key non-extractable; prefer platform keystores in native apps.

Operational checklist

Rotate issuer keys and distribute their public half to all services.
Enforce DPoP on every protected endpoint and run a small jti replay cache.
Keep capability TTLs short; implement a refresh flow with a narrow-scoped refresh capability.
Log cap.jti, sub, and authorization decisions for audits.
Use deterministic resource matching and HTTP method checks in capability evaluation.

What about multi-device and recovery?

Use delegation. A primary device issues a short-lived delegation capability to the new device’s jkt via QR or pairing code. The server then grants that device first-party capabilities. For recovery, rely on out-of-band ownership proofs—such as a purchase receipt or an emailed link that mints a new device capability—instead of a persistent account.

MERN integration notes

React: hydrate app state from capabilities, no cookies. Use SWR/React Query and attach DPoP to each request.
Node/Express: middleware as shown; add route-level capability specs so they can be checked statically.
MongoDB: index audit logs by cap.jti and sub for incident triage. Avoid PII storage.
Next.js/SSR: don’t embed private keys; sign on the client or via server actions tied to device-bound refresh flows.

Closing thoughts

Zero-account means the device carries its identity and its rights. Pair capability tokens with DPoP, keep TTLs short, and bind everything to the device key. You get stateless, least-privilege authorization with less operational load than a traditional auth server, and a clear path to delegation and rotation as you grow.

Serialization Adapters: How I Cut Payloads by 94%

Yaseen Khatib — Tue, 22 Sep 2026 09:27:24 +0000

[ EXECUTIVE TEARDOWN // TL;DR ]

Separate the render model (UI) from the transport model (DB) with an adapter that owns the only conversion.
Anything derivable — dimensions, selection, handle geometry — is recomputed on load, never stored.
The 94% reduction is the sum of removing framework metadata and rounding coordinates, not a codec trick.
Most payload-size problems are boundary problems: you're shipping the cache because no line was drawn.

Rich UI objects are great for rendering and lousy as records. In IntegrateX — a node-graph automation tool — the node you drag around the canvas is packed with measured geometry, hover/selection flags, handle maps, and framework internals. Persist that verbatim and every save ships kilobytes of cached view state, sync gets chatty, and real-time edits run into backpressure. I put a Serialization Adapter at the boundary, kept only the domain fields, and dropped the UI scaffolding. Net: 94% smaller payloads and predictable sync.

Two models, one boundary

The naive approach fuses two things that must stay separate: the render model (what the UI needs to draw) and the transport model (what the wire and database require). The adapter translates both ways, and nothing crosses without it. This is the Data / Serialization Adapter in the pattern I call Trinity Architecture: Presentation renders and dispatches only, a Reactive State / Orchestration layer owns the runtime truth and optimistic updates, and the Adapter shapes lean records for the wire. No layer talks past its neighbor — the UI never formats DB schemas, and the adapter never pokes UI state directly.

adapter.ts

// render model → lean transport record (and back)
export const toRecord = (node: FlowNode): NodeRecord => ({
  id: node.id,
  type: node.type,
  x: Math.round(node.position.x),
  y: Math.round(node.position.y),
  config: node.data.config,   // the only domain data that matters
});

export const fromRecord = (r: NodeRecord): FlowNode =>
  hydrate(r, defaults(r.type));   // recompute view state, don't store it

Derived, never stored

The lever behind the compression is simple: anything that can be derived must not be stored. Dimensions come from layout. Selection is ephemeral. Handle geometry is a function of node type. Persisting them is persisting a cache. In IntegrateX, the orchestrator (Zustand in the middle of my Trinity split) recomputes those bits on load and on change, so the transport stays lean while the UI stays reactive.

The 94%, decomposed

This wasn't a clever codec; it was subtraction. Drop measured geometry, per-node flags, duplicated handles, and framework metadata. Round coordinates to integers. A node that used to serialize to roughly a kilobyte collapses to a few dozen bytes. Multiply by a hundred-node graph, and you reclaim the budget for save, load, and real-time sync — fewer bytes on the wire, fewer renders, less state-synchronization lag.

Most payload-size problems aren't compression problems — they're boundary problems. You're shipping the cache because nobody enforced the line between the view and the record.

For the state-management side of the same project — optimistic updates, sync ordering, and throttled broadcasts — see Compressing the Wire; the system is IntegrateX. I reach for this boundary discipline by default now — the engineer who draws the line between view and record early is the one whose sync layer still behaves at a hundred nodes.

~/keep-reading

Yaseen Khatib · MERN + AI Architect

Ships autonomous AI products solo — five in the last twelve months. More about Yaseen →

Need an engineer who can build this?

I'm Yaseen Khatib — a Senior Full-Stack AI Engineer (MERN + TypeScript) who ships production AI systems solo. Open to senior and lead roles, remote or on-site.

Get in touch →See what I've shipped

Originally published at yaseenkhatib.streamerosai.com/blog/custom-serialization-adapters/.

The 10x Reality: How AI Replaced the Traditional MERN Squad

Yaseen Khatib — Tue, 22 Sep 2026 09:27:22 +0000

[ EXECUTIVE TEARDOWN // TL;DR ]

AI has moved the developer's role from writing syntax to directing architectural flow.
A single architect with Claude can design, build, and ship a full Database → Backend → Frontend pipeline in the time a 10-person team once needed.
The only remaining bottleneck is deep comprehension of the system's data flow.
Velocity now scales with architectural clarity, not headcount.

For most of my career, throughput was something you bought with headcount. More endpoints, add backend engineers; more screens, add frontend engineers. That model just snapped. The limiter was never hands on keyboards — it was the latency between clear architectural intent and working code spread across three layers. AI has crushed that translation latency to near zero.

The bottleneck was never typing

Walk the timeline of a standard MERN feature. A lead sketches the data model. Backend builds the Mongoose schema, controller, validation, routes. Another engineer wires the service layer. Frontend ships the form, the fetch hook, the optimistic update, the error states. Someone else writes tests. Strip the meetings and merge conflicts and you see the uncomfortable truth: roughly 80% of that work was mechanical translation, not decisions. We already knew what to build; we were slowly re-encoding a known architecture into code.

That 80% is what AI now absorbs. Not the thinking — the scaffolding, wiring, and the thousand tiny consistency choices that quietly turn a week into a sprint.

From writing code to directing flow

The discipline that replaces manual coding is AI Orchestration: declare a single contract — the canonical data shape and its boundaries — and direct an agent to materialize it through every layer. Stop writing the database record, the endpoint, and the React hook as three separate artifacts. Declare the contract; generate the layers to satisfy it. I keep this inside the pattern I call Trinity Architecture: Presentation renders and dispatches only; Reactive State / Orchestration holds the runtime truth and coordinates events; the Data / Serialization Adapter shapes rich in-memory state into lean, durable payloads. No layer talks past its neighbor.

orchestrate.ts

// the architect declares intent; the orchestrator fills the layers
const system = await orchestrate({
  contract: caseRecordSchema, // single source of truth (zod)
  layers: ["db", "api", "ui"],
  guardrails: { types: "strict", review: "human" },
});

This is not autocomplete. Autocomplete predicts the next token in a file you're already writing. Orchestration operates a layer up: the contract is the spec and the codebase is the build target. Your leverage stops being WPM and starts being how precisely you specify.

The orchestration loop

Every productive AI build runs the same loop: declare the contract, generate a layer, verify it against the contract, integrate, repeat. The engineer's attention sits entirely on the seams — where one layer hands data to the next. Get the seams right and the interiors are commodity. Miss a seam and you get schema drift, broken optimistic updates, cache churn, and render thrash no amount of generated code can hide.

The only bottleneck left: data-flow comprehension

There is exactly one thing AI cannot do for you, and it has always mattered most: decide how data should move through your system. The shape of the records, the boundaries between services, the contracts that cross them, the indexes that make the queries cheap — these are architectural decisions, and they remain stubbornly, permanently human. Whoever holds the clearest mental model of the data's journey from Database → Backend → Frontend is now the entire critical path. On IntegrateX — a React Flow workflow canvas with real-time node execution and Zustand state — the hard problems were all flow and serialization. A Serialization Adapter stripped canvas-only UI metadata before persistence and cut payload sizes 94%, which in turn fixed state-sync lag during bursts. The adapter never touched UI state; it only spoke through the orchestrator. That boundary discipline is what kept real-time stable.

The era of bloated engineering teams is over. An AI-specialized architect can execute the output of a 10-person squad because the work that remains is comprehension, and comprehension does not parallelize without heavy coordination cost.

What the 10x architect actually does

Owns the data contract — one authoritative schema that every layer is generated to satisfy, eliminating drift between DB, API, and UI, and enforcing my Trinity split so the UI never formats DB shapes and the adapter never reaches into state.
Designs the boundaries — service and module cuts, where validation lives, which seams are stable versus allowed to change, and how events move across them.
Reviews AI output adversarially — not for style, but for the failure modes models won't surface: auth and tenancy, idempotency, pagination limits, streaming and backpressure, edge-case correctness and silent data loss.
Treats prompts as architecture specs — versioned, precise, and scoped; an ambiguous prompt is just an ambiguous requirement with faster failure.

The economic reality

A ten-person squad does not deliver ten units of work. It delivers maybe five after the tax: standups, handoffs, context rebuilds, merge conflicts, and the mismatch between the schema one person imagined and the one another implemented. A single architect directing AI pays none of that tax. There are no handoffs because there is one context. There is no schema drift because there is one contract. The output isn't incrementally faster — it's structurally different.

This is why the staffing question for greenfield product work is changing from how many engineers to how clear is the architecture. Velocity now scales with architectural clarity, not headcount — and that is far cheaper to buy.

If you want to see what this looks like shipped, the project breakdowns walk through production systems — agentic RAG pipelines, real-time admin portals, a real-time telemetry cockpit — each built and taken to production this way.

~/keep-reading

Yaseen Khatib · MERN + AI Architect

Ships autonomous AI products solo — five in the last twelve months. More about Yaseen →

Need an engineer who can build this?

I'm Yaseen Khatib — a Senior Full-Stack AI Engineer (MERN + TypeScript) who ships production AI systems solo. Open to senior and lead roles, remote or on-site.

Get in touch →See what I've shipped

Originally published at yaseenkhatib.streamerosai.com/blog/the-10x-reality-ai-replaced-the-mern-squad/.

The Day ChatGPT Changed Full-Stack Engineering

Yaseen Khatib — Mon, 21 Sep 2026 10:09:39 +0000

[ EXECUTIVE TEARDOWN // TL;DR ]

Late 2022 made writing code cheap for everyone at once, invalidating every estimate of how long features take.
The bottleneck moved from typing to judgment — the model amplifies architectural clarity and confusion alike.
MERN's typed, structured surface is exactly what models navigate well, positioning full-stack engineers to win.
Treat AI as a multiplier on sound architecture, not a substitute for understanding the system.

Late 2022 flipped the table: code went from scarce to cheap almost overnight. Not gradual, not gated by early adopters — everyone got the same accelerant at once. A general-purpose model could read intent and emit working code, turning the slowest part of the job — translating a design into syntax — into a conversation. Timelines based on keystrokes and boilerplate instantly stopped mapping to reality.

From Stack Overflow to a collaborator

The old loop: hit a snag, trawl threads, stitch together an answer, adapt, repeat. The new loop: describe the target — a React prop contract, a clean RTK Query slice, a Mongoose schema with indexes — and get a runnable draft that already speaks the local idioms. The grind that used to tax most days — glue code, adapter shims, the same five edge cases — mostly evaporated. What was left was the actual work: shaping behavior, owning the seams, and deciding where state lives.

The bottleneck moved to judgment

When typing is cheap, correctness of intent is the constraint. The people who got faster weren't “better prompters”; they carried a crisp architecture and steered the model to it. The pattern I call Trinity Architecture did the heavy lifting for me: a strict split between Presentation (React components that only render and dispatch), Reactive State / Orchestration (Zustand, RTK Query, or an event bus as the runtime source of truth with optimistic updates), and a Data / Serialization Adapter (the bridge that converts rich in-memory state to lean wire payloads). Keep those boundaries and the model locks into the grain; blur them and it produces fast spaghetti — state-synchronization lag, render thrash, and vague code that compiles but won't survive real-time pressure.

What it meant for MERN engineers

Full‑stack folks were sitting on the right surface area. MERN with TypeScript — contracts from Mongo through Express to React — is exactly the structured domain models navigate well. On IntegrateX, a React Flow workflow canvas with real-time node execution on a Zustand store, the model could draft nodes, hooks, and endpoints quickly. But the leap came from honoring the Trinity split and inserting a Serialization Adapter at the data boundary: it stripped non-essential React Flow UI metadata before persistence and cut payloads 94%. The model wrote the first pass; judgment decided what was wire-worthy, what stayed in orchestrated client state, and how to keep optimistic updates from outrunning the backend.

The day code became cheap to write was the day architecture became the job. Everything else is an implementation detail moving at 10x speed.

The next arc — RAG, orchestration, type‑safe outputs — sits downstream of that shift. It's why the work on IntegrateX, streamerOS, Path Saathi, and SANKALP reads like systems design under new physics: same constraints, but now the time goes to boundaries, contracts, and flow control instead of scaffolding.

~/keep-reading

Yaseen Khatib · MERN + AI Architect

Ships autonomous AI products solo — five in the last twelve months. More about Yaseen →

Need an engineer who can build this?

I'm Yaseen Khatib — a Senior Full-Stack AI Engineer (MERN + TypeScript) who ships production AI systems solo. Open to senior and lead roles, remote or on-site.

Get in touch →See what I've shipped

Originally published at yaseenkhatib.streamerosai.com/blog/chatgpt-changed-full-stack-engineering/.

I Shipped 5 Products in 12 Months — Solo, Unfunded, and Faster Than Most Teams Ship One

Yaseen Khatib — Mon, 21 Sep 2026 10:09:38 +0000

[ EXECUTIVE TEARDOWN // TL;DR ]

Five production products shipped in twelve months by one engineer: streamerOS, IntegrateX, Sable, a zero-cost content engine, and a LinkedIn automation pipeline.
Solo means every architecture, trust-boundary, and economics decision was made by one head — AI supplied throughput, not vision.
Each product was built to remove a recurring job from my life; that automation mindset transfers directly to company work.
One engineer who has shipped alone has verifiably done the work of PM, backend, frontend, DevOps, and QA.

In the last twelve months I designed, built, and shipped five production products — a realtime telemetry cockpit, a node-based workflow engine, a local-first AI finance agent, an autonomous content pipeline, and a LinkedIn outreach machine. No team. No funding. No standups. Every architecture decision, every line of infrastructure, every product call came from one place: my own head.

This post is not a humble-brag. It is a thesis about how software gets built now — and what a company actually buys when it hires an engineer who has done this.

The portfolio, in one table

streamerOS — a realtime telemetry cockpit for streamers: live system telemetry, multi-platform chat velocity, and automated OBS scene control, rendering at 60fps on a fraction of Electron's memory.
IntegrateX — a React Flow workflow-automation canvas whose custom serialization adapter cut graph payloads by 94%, making save/load feel instant.
Sable — a local-first AI financial agent. All data lives on-device in SQLite; the model proposes, a human confirms, and nothing financial ever leaves the phone.
The Zero-Cost AI Blog Writer — a pipeline that drafts, commits, and deploys technical articles on a cron schedule for exactly $0 of infrastructure.
The LinkedIn Pipeline — an autonomous system that turns my shipped work into scheduled LinkedIn content and grew my professional network while I slept.

What does "solo" mean when AI writes the code?

Solo does not mean I typed every character by hand like it's 2015. It means every decision was mine: the data model, the trust boundaries, the failure modes, the economics. I use Claude as a workforce and MCP as the wiring between it and my systems — but AI is leverage, not vision. A model can generate a component; it cannot decide that a finance app should never let the model touch the money, or that a streaming cockpit should hold its own state in process because streamers run OBS, a game, and an encoder on the same machine. Those calls are the product. The rest is throughput.

The scarce skill in 2026 is not writing code. It is holding an entire product in your head — data flow, trust boundaries, unit economics — clearly enough that the code becomes an output, not a struggle.

The compounding trick: products that work for you

The pattern across all five products is that each one removed a job from my life. The blog writer removed content production. The LinkedIn pipeline removed outreach. Sable removed money anxiety. streamerOS removed the four-apps-and-a-prayer streaming setup. I did not build demos — I built employees, and they have been on shift ever since. That is the mindset I bring to a company: look at the recurring work, ask which of it deserves a human, and ship a system for the rest.

What this proves to an employer

A candidate who has shipped five products alone has, by construction, done the job of a product manager, a backend engineer, a frontend engineer, a DevOps engineer, and a QA function — and paid the price for every mistake personally. There is no diffusion of responsibility in a team of one. When I say I understand systems end-to-end, the evidence is deployed, running, and documented across this site — every product has a full architecture breakdown in the products section.

The next nine posts in this series each take one of these systems — or one of the operating principles behind them — and show exactly how it was built, why it was built that way, and what the same thinking would do inside your company.

~/keep-reading

Yaseen Khatib · MERN + AI Architect

Ships autonomous AI products solo — five in the last twelve months. More about Yaseen →

Need an engineer who can build this?

I'm Yaseen Khatib — a Senior Full-Stack AI Engineer (MERN + TypeScript) who ships production AI systems solo. Open to senior and lead roles, remote or on-site.

Get in touch →See what I've shipped

Originally published at yaseenkhatib.streamerosai.com/blog/shipped-5-products-solo-12-months/.

Stop mixing render and domain state in React dashboards

Yaseen Khatib — Mon, 21 Sep 2026 01:49:26 +0000

What’s the difference between render state and domain state?

Render state drives pixels: selection, panel open/close, column order, scroll offsets, hover, active tab, in-flight drag positions. Domain state is the business data from the server, normalized and cached, with mutations and invalidation. When these are mixed, you get re-render storms, bloated payloads, and painful debugging.

I keep them apart. Domain state lives in a server-state cache (TanStack Query v5.47 or RTK Query 2.2.4). Render state lives in a tiny client store (Zustand 4.5.x) or local component state. Components read from both through selectors. Nothing else.

How do you separate render state from domain state in React?

Keep domain data in a server cache (TanStack Query/RTK Query) keyed by query params; keep UI state (sort, filters, selection, layout) in a co-located client store (Zustand). Components subscribe to minimal slices with shallow equality. Domain and UI layers talk only via dispatched events and props, not direct imports across layers.

Here’s a concrete cut on React 18.3, TypeScript 5.5.

// ui/store.ts
import { create } from 'zustand'
import { subscribeWithSelector } from 'zustand/middleware'

export type Sort = { column: string; dir: 'asc' | 'desc' } | null

interface TableUIState {
  sort: Sort
  filters: Record<string, unknown>
  selection: Set<string> // transient, not persisted
  columnOrder: string[]
  columnWidths: Record<string, number>
  scrollTop: number
  expandedRowIds: Set<string>
}

interface DashboardUIState {
  table: TableUIState
  modals: { inspectorOpen: boolean }
  // actions
  setSort: (sort: Sort) => void
  toggleSelect: (id: string) => void
  setColumnWidth: (col: string, px: number) => void
  setScrollTop: (y: number) => void
}

export const useUI = create<DashboardUIState>()(
  subscribeWithSelector((set, get) => ({
    table: {
      sort: null,
      filters: {},
      selection: new Set(),
      columnOrder: [],
      columnWidths: {},
      scrollTop: 0,
      expandedRowIds: new Set(),
    },
    modals: { inspectorOpen: false },
    setSort: (sort) => set((s) => ({ table: { ...s.table, sort } })),
    toggleSelect: (id) => set((s) => {
      const next = new Set(s.table.selection)
      next.has(id) ? next.delete(id) : next.add(id)
      return { table: { ...s.table, selection: next } }
    }),
    setColumnWidth: (col, px) => set((s) => ({
      table: { ...s.table, columnWidths: { ...s.table.columnWidths, [col]: px } }
    })),
    setScrollTop: (y) => set((s) => ({ table: { ...s.table, scrollTop: y } })),
  }))
)

// data/orders.ts (TanStack Query v5)
import { useQuery, QueryClient } from '@tanstack/react-query'

export const queryClient = new QueryClient({
  defaultOptions: {
    queries: { staleTime: 30_000, gcTime: 5 * 60_000, refetchOnWindowFocus: false },
  },
})

type Order = { id: string; status: string; total: number; createdAt: string }

type OrdersResponse = { items: Order[]; total: number }

function normalize(resp: OrdersResponse) {
  const byId: Record<string, Order> = {}
  for (const o of resp.items) byId[o.id] = o
  return { ids: resp.items.map((o) => o.id), byId, total: resp.total }
}

export function useOrders(params: { status?: string; q?: string; page: number; pageSize: number }) {
  const key = ['orders', params]
  return useQuery({
    queryKey: key,
    queryFn: async () => {
      const qs = new URLSearchParams(params as any).toString()
      const res = await fetch(`/api/orders?${qs}`)
      if (!res.ok) throw new Error(`HTTP ${res.status}`)
      return (await res.json()) as OrdersResponse
    },
    select: normalize,
    keepPreviousData: true,
  })
}

// components/OrdersTable.tsx
import { useOrders } from '../data/orders'
import { useUI } from '../ui/store'
import { useVirtualizer } from '@tanstack/react-virtual'

export function OrdersTable() {
  const sort = useUI((s) => s.table.sort)
  const selection = useUI((s) => s.table.selection)
  const setScrollTop = useUI((s) => s.setScrollTop)

  const { data, isFetching } = useOrders({ page: 1, pageSize: 500, status: undefined })
  const rows = data ? data.ids.map((id) => data.byId[id]) : []

  const parentRef = React.useRef<HTMLDivElement>(null)
  const rowVirtualizer = useVirtualizer({
    count: rows.length,
    getScrollElement: () => parentRef.current,
    estimateSize: () => 36,
    overscan: 10,
  })

  return (
    <div ref={parentRef} style={{ height: 600, overflow: 'auto' }} onScroll={(e) => setScrollTop((e.target as HTMLDivElement).scrollTop)}>
      <div style={{ height: rowVirtualizer.getTotalSize(), width: '100%', position: 'relative' }}>
        {rowVirtualizer.getVirtualItems().map((vi) => {
          const row = rows[vi.index]
          const checked = selection.has(row.id)
          return (
            <div key={row.id} style={{ position: 'absolute', top: 0, left: 0, width: '100%', transform: `translateY(${vi.start}px)` }}>
              <Row row={row} checked={checked} />
            </div>
          )
        })}
      </div>
      {isFetching ? <div className="dim">Loading…</div> : null}
    </div>
  )
}

Important details that keep this fast:

The UI store holds only render concerns. No domain objects.
The server cache owns data fetching, normalization, and memoized selection.
Components subscribe via small selectors (e.g., s.table.sort), not the whole store.
Virtualization avoids mounting 50k DOM nodes.

This is the three-layer split I call Trinity Architecture: presentation components render from state and dispatch events; a reactive client state holds UI and orchestrates; and a data/serialization adapter bridges persistence. Layers never talk past neighbors.

Common symptom when you don’t split

setState in render or mixing stores often triggers: “Warning: Cannot update a component (X) while rendering a different component (Y).” Lift transient UI updates into the render store and update in events/effects.
Changing a large Redux slice that holds both UI and data causes 100+ dependent components to rerender. Selecting fine-grained slices in a small UI store reduces this.

How do you persist large dashboard state without bloating payloads?

Persist only stable layout and configuration, never raw data or transient UI noise. Introduce a small serialization adapter that strips ephemeral fields and converts non-serializable structures (Sets) to arrays. Store this layout JSON separately from data queries, versioned and small.

Example adapter for saving a dashboard layout to the server. This cut has kept payloads under 3–8 KB for complex boards; typical “save everything” payloads on real dashboards end up 200–800 KB due to selections and widths.

// ui/serialize.ts
import { useUI } from './store'

type PersistedLayoutV1 = {
  v: 1
  table: {
    sort: { column: string; dir: 'asc' | 'desc' } | null
    filters: Record<string, unknown>
    columnOrder: string[]
    columnWidths: Record<string, number>
    // intentionally no selection, no scrollTop
  }
  modals: { inspectorOpen: boolean }
}

export function buildPersistedLayout(state: ReturnType<typeof useUI.getState>): PersistedLayoutV1 {
  return {
    v: 1,
    table: {
      sort: state.table.sort,
      filters: state.table.filters,
      columnOrder: state.table.columnOrder,
      columnWidths: state.table.columnWidths,
    },
    modals: state.modals,
  }
}

export async function saveLayout(userId: string) {
  const layout = buildPersistedLayout(useUI.getState())
  await fetch(`/api/users/${userId}/layout`, {
    method: 'PUT',
    headers: { 'content-type': 'application/json' },
    body: JSON.stringify(layout),
  })
}

export function hydrateLayout(layout: PersistedLayoutV1) {
  // cautiously merge only known keys to avoid clobbering live transient state
  useUI.setState((s) => ({
    table: {
      ...s.table,
      sort: layout.table.sort,
      filters: layout.table.filters,
      columnOrder: layout.table.columnOrder,
      columnWidths: layout.table.columnWidths,
    },
    modals: layout.modals,
  }))
}

This “serialization adapter” is purposefully boring. It’s a whitelist. It strips non-essential UI metadata, which also future-proofs the layout format. On one production workflow tool (IntegrateX), a similar adapter cut saved graph payloads by about 94% by excluding React Flow render geometry.

If you must persist heavy mappings such as selection of thousands of rows, cap it. For instance, keep at most 500 IDs, and coerce it to an array of stable strings. Anything more should be re-derived on load from a saved filter.

How do you avoid re-render storms with large datasets?

Normalize server data and expose cheap selectors. - Keep UI state small and use fine-grained selectors with shallow compare. - Virtualize long lists and avoid inline object/array props. - Batch mutations and use startTransition when flipping large UI flags.

Concrete knobs that matter:

TanStack Query select normalization keeps referential stability. Derived “row” objects change only when their id actually changes.
Zustand selectors: use (s) => s.table.sort not (s) => s.table. If you must select multiple keys, memoize or use shallow.

import { shallow } from 'zustand/shallow'
const [sort, columnOrder] = useUI((s) => [s.table.sort, s.table.columnOrder], shallow)

Avoid creating new objects in JSX props on hot paths. Move them out or use useMemo.

const columns = React.useMemo(() => buildColumns(columnOrder), [columnOrder])
<Table columns={columns} />

For bulk UI updates that trigger lots of child work, wrap in a transition.

const [pending, startTransition] = React.useTransition()
const onToggleAll = () => startTransition(() => useUI.getState().toggleAllVisible())

Typical figures to keep in mind (illustrative only): 50–100k rows of JSON over a 4G link is 8–20 MB and costs 1.5–4 s network + 100–250 ms parse/GC on an M1. Don’t fetch that. Paginate server-side and virtualize client-side.

What’s the SSR/Next.js 14 story without hydration bugs?

Prefetch domain data on the server and dehydrate it; create UI state only on the client after mount. Don’t embed UI state in the HTML. If you must seed it, keep it minimal and idempotent, and merge during a client effect, not during initial render.

Sketch for Next.js 14.2 with TanStack Query dehydrate:

// app/orders/page.tsx
import { dehydrate, Hydrate } from '@tanstack/react-query'
import { queryClient } from '@/data/orders'

export default async function Page() {
  await queryClient.prefetchQuery({ queryKey: ['orders', { page: 1, pageSize: 50 }], queryFn: fetchOrders })
  const state = dehydrate(queryClient)
  return (
    <Hydrate state={state}>
      <OrdersPageClient />
    </Hydrate>
  )
}

// app/orders/OrdersPageClient.tsx
'use client'
import { useEffect } from 'react'
import { hydrateLayout } from '@/ui/serialize'

export function OrdersPageClient() {
  useEffect(() => {
    // fetch persisted layout and hydrate into UI store after mount
    fetch('/api/me/layout').then((r) => r.json()).then(hydrateLayout).catch(() => {})
  }, [])
  return <OrdersTable />
}

Two rules that prevent hydration mismatches:

Never render from a UI store value that differs between server and client during the initial paint.
If a UI default must depend on window or layout, compute it in useEffect and update the store there.

Real-time and AI panels: keep tokens out of domain state

For streaming telemetry or AI summaries, treat partial tokens/lines as render state. Domain state should track the final artifact and its metadata.

// ai/summarize.ts - SSE streaming client
export function streamSummary(taskId: string, onToken: (t: string) => void) {
  const es = new EventSource(`/api/tasks/${taskId}/summary/stream`)
  es.addEventListener('token', (e) => onToken((e as MessageEvent).data))
  es.addEventListener('done', () => es.close())
  return () => es.close()
}

// components/SummaryPanel.tsx
import { useUI } from '@/ui/store'
import { useEffect, useState } from 'react'

export function SummaryPanel({ taskId }: { taskId: string }) {
  const [text, setText] = useState('') // render state only
  useEffect(() => streamSummary(taskId, (t) => setText((prev) => prev + t)), [taskId])
  return <pre className="summary">{text}</pre>
}

Persist only the final text (domain) as part of task metadata through a normal mutation. Do not shove partial token streams into your global stores.

When not to do this

Small CRUD with <10 screens and <2k rows/page: local component state + a single query cache is fine. Splitting stores adds cognitive overhead and boilerplate.
Teams without discipline on selectors and memoization can end up with two anti-patterns instead of one. Keep the rules enforced in code review.
Heavy cross-slice coupling: if a mutation in domain must atomically update multiple UI concerns, put a thin orchestrator function next to the UI store; don’t call the data cache directly from view code.

Failure modes to watch

Over-persisting UI: saving selection sets, hover rows, scroll positions balloons payloads and creates janky restores.
Non-serializable UI state in devtools: Sets/Maps are fine in-memory but convert at persistence boundaries.
Thundering updates: writing to the UI store from tight mousemove handlers without requestAnimationFrame batching will stutter.
WebSocket or RTU messages that include render-only fields will hurt mobile users; keep wire payloads to business data.

Tooling and versions that work

React 18.3, Next.js 14.2
Zustand 4.5.x with subscribeWithSelector
TanStack Query 5.47 (or RTK Query 2.2.4 if you’re already on Redux Toolkit 2.2.x)
@tanstack/react-virtual 3.x or AG Grid 31.x for big tables
TypeScript 5.5, Node 20.16 LTS

A quick install baseline:

pnpm add zustand @tanstack/react-query @tanstack/react-virtual

A minimal checklist

Domain state: queries/mutations, normalized, cached, invalidated by keys.
Render state: sort, filters, column order, selection, scroll, modals.
Serialization adapter: whitelist-only persisted layout, versioned.
Components: subscribe to minimal slices; virtualize long lists; memoize heavy props.
SSR: dehydrate domain data; hydrate UI after mount.

One blunt question to keep taped to the monitor: will this value cross a process boundary (persist, sync, or query)? If yes, it belongs to domain state; if not, keep it in render state. Keeping that line bright is most of the battle.