DEV Community: Parvej Shah

We Can Build Software Faster Than Ever. But Can Users Actually Use It?

Parvej Shah — Thu, 17 Sep 2026 05:52:02 +0000

Originally published at parvejshah.com/blog/rapid-software-development-user-experience by Parvej Shah.

Software development has become remarkably fast.

Agile shortened development cycles. Modern component libraries stopped us from reinventing UI primitives. Cloud platforms removed infrastructure headaches, and APIs turned complex features into one-line integrations.

Now AI-assisted development is accelerating that cadence even further. Prototypes that once required weeks can take shape in a few hours.

That is genuine progress. But it brings us face-to-face with a harder question:

We can build software faster than ever. But can users actually use what we're building?

Because development speed and product usability are not the same thing. And as our competitors get faster too, the standard users measure us against is constantly shifting.

We optimized the developer's side of software

Inside software teams, progress usually sounds like this: sprint complete, API connected, tests passing, feature deployed.

To an engineer, these are major milestones. But to the user, they are completely invisible.

Users don't care whether you work in Scrum or Kanban, or whether code was written by hand or generated with an AI assistant. Their question is straightforward:

"I came here to accomplish something. Does this product help me do it?"

This creates two fundamentally different journeys:

For developers:
Idea → Sprint → Build → Test → Deploy

For users:
Need → Understand → Act → Feedback → Outcome

We can complete the first journey flawlessly while making the second one terrible.

Shipping something quickly isn't the same as making it usable.

Rapid prototyping was never meant to mean "build more"

When AI lets a team build ten features in the time it previously took to build two, the default instinct is simple: build ten features.

That misses the real opportunity.

The biggest advantage of rapid prototyping isn't producing more code. It's testing assumptions sooner.

Instead of spending months perfecting an idea internally, we can get a working slice in front of real users, observe where they stumble, and iterate.

The loop shifts from Build → Build → Build → Launch to:

Build → Observe → Learn → Improve → Repeat

The first optimizes output. The second optimizes learning. If our core assumptions are flawed, increasing output just means producing the wrong thing faster.

The true promise of rapid software development is shorter learning time, not just shorter coding time.

The rising UX bar: "Good enough" is moving

Users' expectations don't stay still while tools improve.

Years ago, rough edges were forgiven because building software was expensive. Today, AI-assisted development, mature design systems, and automated testing make iteration dramatically cheaper.

And your competitors have access to those exact same tools.

Users don't need to understand AI to raise their standards. They experience a product where signup takes 20 seconds, feedback is instant, and redundant steps are gone. When they return to your app, friction that once felt acceptable suddenly feels frustrating.

Users compare experiences, not development histories.

They don't compare your app to what was possible five years ago. They compare it to the best experience they used five minutes ago.

What makes rapidly built software actually usable?

Speed doesn't replace the fundamentals of UX — it amplifies their importance:

Clarity: The user shouldn't have to decode the interface. Refinement means they intuitively know what to do next without friction.
Low Friction: Implementation complexity must never become the user's burden. Every redundant form field or unnecessary screen has a cost.
Responsive Feedback: Technical correctness means nothing if the UI leaves users hanging. Communicate state immediately: loading, processing, confirmed.
Predictability: Consistent patterns build mental models. When software behaves as expected, users stop thinking about the tool and focus on their task.
Real Outcomes: Does the feature solve the user's problem? Software is a vehicle; delivering the user's intended outcome is the destination.

The bottleneck is moving

As AI drives the marginal cost of writing code toward zero, implementation is no longer the primary bottleneck.

The real constraints are understanding problems:

What should we build in the first place?
Where are real people struggling?
What should we remove instead of adding?

We are reducing the cost of building software much faster than the difficulty of understanding human behavior.

Velocity shouldn't just measure how many tickets were closed. It should measure how quickly a team moves from assumption to evidence.

If a feature takes half the time to build with AI, what should we do with the remaining time?

Build another feature? Or use that time to observe, refine, and make the first one genuinely exceptional?

Parvej Shah is a Lead Full-Stack Web Developer & Platform Architect based in Dhaka, Bangladesh. Explore full architecture case studies and production code at parvejshah.com.

Why Browser Agents Fail in Production Without Semantic Layers

Parvej Shah — Thu, 27 Aug 2026 18:17:15 +0000

Originally published at parvejshah.com/blog/why-browser-agents-fail-in-production-without-semantic-layers by Parvej Shah.

The Fragility of Machine Vision in Modern DOMs

Maybe the next evolution of frontend engineering isn't just designing interfaces for humans. It is designing interfaces that machines can reliably understand too.

Browser agents don't always fail because the AI model is bad. Often, the web page itself is fundamentally hostile to machine parsers. Modern single-page applications (SPAs) render deeply nested <div> trees with ephemeral, auto-generated class names (such as Tailwind or CSS-in-JS hashes). While this provides fluid visual rendering for human users, it strips away semantic meaning for automated agents.

graph TD
  A[AI Browser Agent] -->|Fragile Visual OCR / Coordinate Guessing| B[Opaque Div Hierarchy]
  B -->|Frontend Code Deploy / CSS Hash Shift| C[Broken Automation & Flaky Selectors]
  A -->|Direct Deterministic Query| D[Semantic Schema & data-agent Attributes]
  D -->|Refactor-Proof Contract| E[Deterministic Task Execution]

Moving Beyond Ephemeral Selectors

We already treat accessibility (a11y) as a non-negotiable contract between the frontend and assistive technologies through ARIA attributes. Why not extend that exact engineering rigor to AI agents?

Imagine components exposing explicit, stable machine intent:

// The machine contract: deterministic, testable, refactor-proof
<button 
  data-agent="checkout-submit-button"
  data-agent-action="complete-transaction"
  className="btn-primary"
>
  Confirm & Pay
</button>

With explicit semantic attributes:

Zero Layout Guesswork: The agent does not need to guess which button to click based on pixel coordinates or fragile CSS selectors.
Deterministic Interaction Paths: Continuous integration (CI) test suites can validate machine contracts alongside accessibility audits.
Reduced Latency & Token Costs: Vision-language models (VLMs) introduce non-deterministic latency and high token costs when inspecting DOM trees. Semantic annotations impose near-zero runtime overhead while guaranteeing parse stability.

Machine Intent as a First-Class Frontend Concern

Frontend development is expanding beyond human visual presentation. Treating machine intent as a first-class citizen transforms web applications into programmable, resilient interfaces that AI agents can navigate with 100% precision.

Parvej Shah is a Lead Full-Stack Web Developer & Platform Architect based in Dhaka, Bangladesh. Explore full architecture case studies and production code at parvejshah.com.

The Stack I Keep Coming Back To and Why I Stop Reconsidering It

Parvej Shah — Wed, 26 Aug 2026 20:34:30 +0000

Originally published at parvejshah.com/blog/craft-of-high-velocity-software-delivery by Parvej Shah.

There's a specific state of mind that a developer can get into where evaluating new tools feels productive. You read release notes, benchmark comparisons, and Twitter threads from early adopters. You build proof-of-concepts. You track GitHub stars and Hacker News reception. This can occupy a significant fraction of your available thinking time.

The output from this activity is rarely a better product. It's usually a well-informed decision to continue using what you were already using.

I've been building full-stack web applications across projects ranging from EdTech platforms to enterprise workforce dashboards to real-time telephony systems. I've done this primarily with PostgreSQL, TypeScript, and Next.js. I keep coming back to this combination — not because I haven't evaluated alternatives, but because I've evaluated enough alternatives to understand what I'd actually be trading.

What "Boring Technology" Means in Practice

The phrase "boring technology" gets misread as a preference for old or unsophisticated tools. That's not the point. The point is familiarity depth.

When I encounter a bug in a Prisma query at 11pm during a client deployment, I know where to look. I understand how Prisma generates SQL, what its transaction semantics are, how connection pooling behaves under load. This knowledge was accumulated across dozens of projects and hours of debugging. When I encounter a problem with an ORM I've used for three weeks, my diagnostic path is much longer.

PostgreSQL covers an enormous surface area of what applications actually need. Full-text search, JSON document storage, relational joins, atomic transactions, row-level security, triggers, recursive CTEs. Every application I've built eventually needed something that Postgres had native support for.

For MathPro Academy, we use PostgreSQL for course data, enrollments, payments, and streak tracking. The streak tracking required a SQL UPSERT with CASE logic that would have been genuinely awkward to implement correctly in most NoSQL databases. PostgreSQL handled it cleanly with a single atomic statement.

TypeScript is a net-positive before you're familiar with it and an unmistakable productivity multiplier after you are. The upfront cost — writing types for your data structures, understanding generics, configuring the compiler — is real. The payoff — catching a null access error at compile time instead of at 3am in a production error log — is also real.

The strictness setting matters. Running TypeScript with strict: false gives you type annotations without most of the safety. strict: true is uncomfortable initially and significantly better in practice.

Next.js solves the API/frontend split that used to require running and coordinating two separate development servers. API routes live in the same codebase as UI components. Server-side rendering and static generation are first-class primitives rather than configurations. The App Router's Server Components model — when you understand it — eliminates entire categories of client-side data fetching patterns that were always the wrong abstraction anyway.

The Real Velocity Driver: Short Feedback Loops

The biggest predictor of delivery speed on any project isn't the language or framework — it's the feedback loop length. How long does it take to go from writing code to knowing whether it works?

In a fast feedback environment:

The development server reflects file changes in under 500ms.
Type errors appear in the editor as you type, not on the next build.
Database schema changes are applied with a single command.
Deployment to staging takes under three minutes.

In a slow feedback environment:

Build times over 30 seconds create cognitive context loss between iterations.
Manual testing steps are required to verify basic functionality.
Deployment pipelines take 15 minutes, so you batch changes instead of shipping incrementally.

The specific tools matter less than whether you've configured them to minimize feedback latency. Turbopack's fast HMR, TypeScript's language server integration with VS Code, Prisma's db push for rapid schema iteration during development — these are the practical affordances that compound into meaningful time savings across a project.

Knowing What to Leave Out

The hardest and most valuable engineering skill is deciding not to build something.

Every feature you build is code that must be maintained, bugs that can occur, edge cases that must be handled, and cognitive load for future developers (often yourself). The features that get cut are free. The features that get built carry ongoing costs.

This applies to infrastructure choices too. Distributed message queues are powerful and complex. For a project where a single Postgres instance is adequate, the complexity of Redis and BullMQ is pure overhead. Microservices offer genuine benefits at scale. For a team of one to three developers building a product for a few hundred users, they introduce deployment complexity that serves no one.

The right time to add architectural complexity is when you have clear evidence that you need it. The evidence is usually a specific bottleneck, a specific scale requirement, or a specific capability gap — not a theoretical concern about future scale.

I've seen more projects slow down from premature architectural complexity than from inadequate infrastructure. A well-designed monolith on a managed Postgres database has shipped and maintained more valuable software than any number of elaborate distributed systems built for scale problems that never materialized.

The stack I keep coming back to isn't remarkable. It's just familiar, capable, and well-understood. That turns out to be enough.

Parvej Shah is a Lead Full-Stack Web Developer & Platform Architect based in Dhaka, Bangladesh. Explore full architecture case studies and production code at parvejshah.com.

What I Actually Had to Change When Moving to React Server Components

Parvej Shah — Wed, 26 Aug 2026 20:34:24 +0000

Originally published at parvejshah.com/blog/nextjs-16-turbopack-deep-dive by Parvej Shah.

When Next.js introduced the App Router with React Server Components, the mental model shift was more significant than the API change. The API changes are well-documented. The mental model shift is harder to articulate and easier to get wrong.

This is a practical account of what changed when building this portfolio site on Next.js 16 with Turbopack — which pages ended up as Server Components, which needed to be Client Components, and what the non-obvious boundary decisions looked like.

The Instinctive Wrong Move

The instinct when you hit a component that seems "complex" is to add "use client" to the top of the file. This works — the component now runs in the browser like it always did — but it often carries a hidden cost.

When you mark a parent component as a Client Component, every component it imports transitively becomes part of the client bundle too. If you've put "use client" on a layout component that imports your navigation, your blog post renderer, and your analytics component, you've just made all of those things client-side JavaScript even if none of them need interactivity.

The correct question isn't "does this component need to be a Client Component?" It's "what is the smallest leaf component that actually needs to run in the browser?"

The Actual Split on This Portfolio

Going through each section of the portfolio site with this question produced a clear pattern:

Everything in the blog system stayed as a Server Component. Blog posts fetch their content from PostgreSQL through Prisma. Markdown gets parsed and rendered. Cover images are served from the public directory. None of this involves user interaction. None of it changes based on client-side state. All of it is better handled on the server.

// This is a Server Component — no "use client"
// It runs at build time for static pages, at request time for dynamic ones

async function BlogPost({ slug }: { slug: string }) {
  const post = await db.post.findUnique({
    where: { slug, status: "PUBLISHED" },
    include: { coverImage: true },
  });

  if (!post) notFound();

  return (
    <article>
      <PostHeader post={post} />
      <MarkdownContent content={post.content} />
    </article>
  );
}

The navigation required a hybrid approach. The navbar is mostly static HTML, but it needs to highlight the active route — which requires knowing the current pathname, a client-side concern. The solution is to keep the navbar structure as a Server Component and extract only the active-state logic into a small Client Component.

// nav-link.tsx — Client Component (needs usePathname)
"use client";

import { usePathname } from "next/navigation";

export function NavLink({ href, children }: NavLinkProps) {
  const pathname = usePathname();
  const isActive = pathname.startsWith(href);

  return (
    <a href={href} className={isActive ? "text-emerald-400" : "text-slate-400"}>
      {children}
    </a>
  );
}

Forms are Client Components. The contact form and the admin dashboard forms require useState, onChange handlers, and submission logic. These are genuinely client-side concerns. Making them Client Components is correct.

Static Generation with Database Content

The blog posts and project pages are statically generated at build time. Next.js calls generateStaticParams to enumerate all the slugs, then pre-renders each page to static HTML.

export async function generateStaticParams() {
  const posts = await db.post.findMany({
    where: { status: "PUBLISHED" },
    select: { slug: true },
  });

  return posts.map(post => ({ slug: post.slug }));
}

When a new blog post is published through the admin interface, it triggers a Vercel deployment. The new build runs generateStaticParams, discovers the new slug, generates its static HTML, and deploys. The post goes live without any runtime database queries for future visitors.

One Actual Gotcha

There's a subtle issue with unstable_cache in Next.js when combined with static generation. The cache is keyed by the arguments you pass to it, but if you change the data in the database without triggering a new deployment, the cache will serve stale data indefinitely.

For content that changes through the admin interface, the admin routes that write to the database call revalidatePath or revalidateTag after each write, which purges the relevant cache entries. Without this, editing a blog post would update the database but leave the static HTML unchanged until the next deployment.

import { revalidatePath } from "next/cache";

async function updateBlogPost(id: string, data: PostUpdateData) {
  await db.post.update({ where: { id }, data });

  // Purge the static cache for this post's page
  revalidatePath(`/blog/${data.slug}`);

  // Purge the blog index page too
  revalidatePath("/blog");
}

This is the part that takes the most deliberate thought — not the Server/Client boundary, but the cache invalidation strategy. Get it right and content updates feel instant. Get it wrong and editors wonder why their changes aren't appearing.

Parvej Shah is a Lead Full-Stack Web Developer & Platform Architect based in Dhaka, Bangladesh. Explore full architecture case studies and production code at parvejshah.com.

How We Made Academic Certificates Verifiable Without a Blockchain (or HMAC)

Parvej Shah — Wed, 26 Aug 2026 20:33:44 +0000

Originally published at parvejshah.com/blog/high-speed-edge-verification-institutional-credentials by Parvej Shah.

When the Center for Policy Research on Business and Development (CPRBD) at the University of Dhaka approached us about their institutional web portal, certificate verification stood out immediately. CPRBD runs executive education cohorts for mid-career government officials and business professionals, who receive physical certificates used as credentials for government postings and senior roles — and nothing on the physical certificate had ever been independently verifiable.

Why a Structured ID Beats a Cryptographic Scheme

Every certificate gets an ID of the form CPRBD-2025-EXEC-B1-001 — year, program code, batch code, and a per-batch serial minted atomically when a certificate is issued. That ID is what's printed on the certificate and encoded in its QR code.

Verification is a direct database lookup: given the ID, look up the enrollment record and return whether it exists and is still valid (not archived, not un-issued). No cryptographic signature, no HMAC, no blockchain. The reason this is enough: CPRBD controls both the issuing authority and the verification endpoint. The trust anchor is CPRBD's own server, not a distributed ledger or a shared secret — an attacker can't mint a valid-looking ID because the serials are sequential and tied to real enrollment rows, not derived from a formula they could reverse-engineer.

What does protect the endpoint is more mundane than cryptography: it's rate-limited to 20 requests per minute per IP, and responses are explicitly marked no-store so nothing caches a stale "valid" or "not found" result.

Payment-Gated, Not Module-Gated (Yet)

Certificates are only issued in bulk to students whose tuition is marked complete — the endpoint filters candidates down to paymentStatus === "complete" before minting anything, and reports back how many were skipped as unpaid. Course-module completion is tracked and shown to admins as a reference count, but it isn't currently enforced before issuance — that's a gap in the platform we're aware of, not a feature we're claiming.

Tuition That Matches How Executive Programs Actually Get Paid

Executive cohorts don't pay tuition in one lump sum. The platform tracks payments as a sequence of installments against SSLCommerz, each with its own status — pending, complete, failed, refunded — and computes the remaining balance as batch fee minus the sum of completed installments. A student's material access and certificate eligibility both key off that same installment ledger, so there's one source of truth for "has this person paid," not a synced copy of it.

Materials Are Private Because They're Never Public

The same "one ledger, two gates" idea shows up again in how class materials are shared. Uploaded files live in a data/ directory outside public/, so there's no static URL Next.js could accidentally serve — the only path to a file's bytes is an authenticated download route. That route re-runs the same check used for material access generally: enrolled, application approved, at least one completed installment. No signed URLs, no expiring tokens — just "don't put it somewhere the framework will serve for free, and check on every request instead."

Each program can also extend its application form with its own questions — beyond the fixed profile fields (contact details, qualifications, nationality, and so on) every applicant fills in once, a program admin can add a text question, a file upload, a date picker, whatever that specific cohort's intake needs — without a code change or a deploy.

A CMS Built for People Who Don't Want to Touch Code

The less visible, more used part of the platform: CPRBD staff maintain their own program pages. Each program's public page is assembled from nine section types — hero, a "why this program" block, stats, testimonials, FAQ, a course outline pulled live from the actual module list, and a few others — that staff can reorder, toggle on or off, and edit inline. Updating a program's pricing blurb or adding a new FAQ entry used to mean a code change; now it's a form.

The same philosophy extends to communication and content: coordinators post batch-scoped announcements that automatically email every enrolled student in that cohort, and a separate news/media module lets CPRBD publish institutional press posts independent of both the CMS and the academic research repository — which itself replaced a static list of published papers buried in a Word document on the university website with structured, searchable entries and attached PDFs.

What We Learned

The interesting engineering here wasn't cryptographic — it was matching the platform's guarantees to what actually needed guaranteeing. A structured, sequential ID plus a rate-limited lookup is enough when you control the whole trust chain; reaching for HMAC or a blockchain would have added complexity without adding real security here. The harder, more valuable work was elsewhere: an installment ledger that's the single source of truth for two different gates (materials and certificates), and enough non-technical surface area — CMS, announcements, news — that CPRBD can run the platform day-to-day without opening a ticket.

None of that came from a tidy requirements document. The people who understood how CPRBD actually ran a cohort were busy university staff, available in short bursts, not for a single upfront discovery phase — so the real user stories got built the same way the platform's admin surfaces did: incrementally, from repeated short conversations rather than one clean spec.

Parvej Shah is a Lead Full-Stack Web Developer & Platform Architect based in Dhaka, Bangladesh. Explore full architecture case studies and production code at parvejshah.com.

Streaks Without Race Conditions: What Actually Runs Behind Codervai CP

Parvej Shah — Wed, 26 Aug 2026 20:33:38 +0000

Originally published at parvejshah.com/blog/scaling-competitive-programming-lms-architectures by Parvej Shah.

Competitive programming requires building a specific kind of knowledge: algorithms and data structures that compose with each other. You can't understand dynamic programming without first being solid on recursion. You can't reason about graph traversal without understanding how to implement a queue. The dependency tree is real, and the order in which concepts are introduced matters.

Codervai CP is a structured competitive programming learning platform. Separately, its daily-streak mechanic has to survive a predictable concurrency problem: a burst of submissions near midnight, all racing to protect a streak before the day resets.

Publishing, Not Pacing

The original plan for content release was a cohort calendar — module 1 from day 0, module 2 from day 7, and so on, mirroring how a university course paces itself. That's not what's actually running. The real mechanism is simpler: an instructor flips a chapter's is_live flag from the admin CMS, and every enrolled student is notified the moment it happens.

That ended up being the better call, not a fallback. A publish button doesn't have timezone edge cases, doesn't need a scheduler that has to stay correct forever, and gives instructors a real escape hatch — a chapter that isn't ready yet just doesn't get published, instead of unlocking on schedule whether it's ready or not.

The Streak Concurrency Problem

Daily streaks are one of the most effective engagement mechanics in learning platforms. At Codervai CP, streaks are awarded for solving at least one problem per day. A student who maintains a 30-day streak has real motivation to protect it.

The concurrency issue is predictable: a significant fraction of streak activity happens near midnight, as students rush to maintain their streak before the day resets. This creates a burst of simultaneous database writes, and the naive implementation of streak tracking breaks under concurrent load.

Consider the naive approach:

// BROKEN: race condition when two submissions arrive simultaneously
async function updateStreak(userId: string): Promise<void> {
  const { rows } = await pool.query(
    'SELECT * FROM "UserStreak" WHERE "userId" = $1',
    [userId]
  );
  const streak = rows[0];
  const today = new Date().toDateString();

  if (streak && new Date(streak.lastActiveDate).toDateString() === today) return;

  const yesterday = new Date();
  yesterday.setDate(yesterday.getDate() - 1);
  const wasActiveYesterday =
    streak && new Date(streak.lastActiveDate).toDateString() === yesterday.toDateString();

  const newStreak = wasActiveYesterday ? streak.currentStreak + 1 : 1;
  await pool.query(
    `INSERT INTO "UserStreak" ("userId", "currentStreak", "lastActiveDate")
     VALUES ($1, $2, NOW())
     ON CONFLICT ("userId") DO UPDATE SET "currentStreak" = $2, "lastActiveDate" = NOW()`,
    [userId, newStreak]
  );
}

If two problem submissions from the same user arrive within milliseconds of each other, both queries execute the SELECT before either has written. Both see the streak as needing an update. Both write. The streak increments by 2 instead of 1.

The actual fix is an atomic upsert at the database level, in one parameterized query, with no application-code read-then-write step at all:

async function recordActivityAndUpdateStreak(userId: string): Promise<void> {
  const today = new Date().toISOString().split("T")[0];

  await pool.query(
    `INSERT INTO "UserStreak" ("userId", "lastActiveDate", "currentStreak", "updatedAt")
     VALUES ($1, $2::date, 1, NOW())
     ON CONFLICT ("userId") DO UPDATE SET
       "currentStreak" = CASE
         WHEN "UserStreak"."lastActiveDate" = ($2::date - INTERVAL '1 day')
           THEN "UserStreak"."currentStreak" + 1
         WHEN "UserStreak"."lastActiveDate" = $2::date
           THEN "UserStreak"."currentStreak"
         ELSE 1
       END,
       "lastActiveDate" = $2::date,
       "updatedAt" = NOW()
     WHERE "UserStreak"."lastActiveDate" < $2::date OR "UserStreak"."userId" IS NULL`,
    [userId, today]
  );
}

The entire logic — check yesterday, check today, compute new streak — is a single atomic database operation, guarded by the trailing WHERE clause: it doubles as same-day idempotency (a second submission the same day is a no-op, not a second increment) and as anti-backdating (a write can't apply against a date older than what's already stored). No application code reads a value and then writes a derived value. Concurrent calls for the same user serialize at the database lock level without corrupting the streak count.

Video: Buy, Don't Build

Editorial code walkthroughs on a competitive programming platform have a specific quality challenge: the content is code on a dark background, and standard video compression optimized for natural scenes tends to blur the fine syntax details that make code legible.

The instinct is to reach for a custom encoding profile — tuned quantization, reduced temporal compression, all the FFmpeg knobs. We didn't build that. Walkthroughs are delivered through BunnyCDN Stream, which handles HLS segmentation and adaptive bitrate on its own, or a plain YouTube embed where that's simpler. Legible video-of-code at reasonable cost is a solved problem one layer up the stack; building a custom transcoding pipeline would have meant maintaining infrastructure that mostly re-implements what a CDN already does well, for a marginal quality gain that never got prioritized against actual product work.

What Held Up, What Didn't

The streak upsert design held up exactly as built — it's still the atomic, single-round-trip operation described above, running unmodified under real midnight traffic. The "cohort pacing" idea didn't survive contact with actual instructors using the platform; a manual publish flow turned out to be both simpler to build and easier for content creators to reason about than a scheduler would have been.

Parvej Shah is a Lead Full-Stack Web Developer & Platform Architect based in Dhaka, Bangladesh. Explore full architecture case studies and production code at parvejshah.com.

AI-Assisted Data Entry: Teaching an LLM to Parse Telegram Donor Messages

Parvej Shah — Wed, 26 Aug 2026 20:32:59 +0000

Originally published at parvejshah.com/blog/offline-first-pwa-emergency-volunteer-networks by Parvej Shah.

The Bottleneck Wasn't Search, It Was Entry

The app runs a Workbox service worker caching static assets, and a NetworkFirst strategy on the API calls that matter — the core donor-lookup workflow still needs a network connection. Offline caching wasn't the interesting problem here.

The real friction Badhan's coordinators had wasn't looking donors up — a blood-group-indexed Postgres query handles that fine. It was getting donor information in. Volunteers were already reporting new donors the way people naturally coordinate things: as free text, in Telegram, in whatever format they happened to type it in. A form nobody consistently fills out correctly is worse than no form at all. So we built two different entry paths for two different shapes of input, instead of forcing one workflow on both.

Path One: Telegram, No AI Involved

Coordinators post donor info directly into a Telegram group. The bot detects donor-shaped messages with a keyword/pattern heuristic — blood group plus a phone number or date is usually enough — and hands the text to a deterministic parser: no LLM call, no API cost, no rate limit to worry about.

Parvej Shah
B+
IIT 23-24
01516538054
25-08-25
Hasanur Rahman
AEH Hall

That's the expected shape: referrer name, donor name, then blood group / phone / date / batch / hall in any order, matched by what each token looks like rather than its position. A comma-separated single-line variant works too. Multiple donors in one message just need a blank line between blocks. The bot replies per donor — ✅ submitted, ⚠️ already exists, or ❌ with the specific validation error — so a bad phone number in donor 3 of 5 doesn't obscure that the other four went through fine.

This path is intentionally not AI. A Telegram group can get bursts of messages, and every one of them gets scanned for the donor-data pattern. Running an LLM call against every group message would be slow, costly, and unnecessary — the format volunteers actually use is regular enough that pattern matching gets it right without asking an API to guess.

Path Two: The Web Submit Page, Where AI Earns Its Keep

There's a second entry point — a plain "paste your donor list" form on the web app — for the messier case: someone dumping a half-formatted list from a spreadsheet, a WhatsApp export, or a batch of records that don't line up with the strict positional format. That's where the AI parser actually lives, and it's built as a three-tier fallback, not a single point of failure:

// 1. Attempt Gemini AI parsing (skipped if useAI is false)
const aiDonors = useAI ? await parseWithGemini(trimmedText) : null;
if (aiDonors && aiDonors.length > 0) {
  return NextResponse.json({ donors: aiDonors, usedAI: true });
}

// 2. Try fixed-format block parser
if (isFixedBlockFormat(trimmedText)) {
  const fixedDonors = parseFixedFormatBlocks(trimmedText);
  if (fixedDonors.length > 0) return NextResponse.json({ donors: fixedDonors, usedAI: false });
}

// 3. Fall back to regex parser
const regexDonors = await parseBulkFormattedText(trimmedText);

Gemini gets a strict extraction prompt: blank-line-separated blocks, a fixed referrer/donor-name convention for the first two lines, and explicit field-identification rules — a blood-group token can be "B(+ve)" or "o+" or "AB(positive)" and should normalize to AB+; a date can be 5-5-26 or 09/04/2026 and should normalize to DD-MM-YYYY; a hall name like "AEH" or "Ae hall" should normalize to AE Hall. The model is told exactly what shape to return and nothing else — a bare JSON array, no markdown fences, no commentary.

Fallback Isn't Optional

Gemini calls fail for boring reasons: rate limits, transient errors, a malformed response the model didn't quite get right. The parser rotates across multiple API keys, and when a key gets a 429 it's marked as cooling down for 10 minutes and skipped on the next attempt rather than retried into more failures:

function markKeyCooledDown(keyState: KeyState): void {
  keyState.cooledUntil = Date.now() + COOLDOWN_MS; // 10 minutes
}

If every key is cooling down, or the response fails to parse as valid JSON, parseWithGemini returns null and the route falls through to the fixed-block parser, then the regex parser. A submission on the web form never just fails because the AI step had a bad moment — it degrades to a dumber but reliable path instead.

What This Buys, and What It Doesn't

The honest version of this feature: two intake paths matched to two real usage patterns, a fallback chain that treats the AI step as an enhancement rather than a dependency, and a UserFeedback table plus an internal review page where coordinators can flag a bad parse for someone to look at later. That last part is a correction log, not a self-improving system — the extraction prompt doesn't change itself based on feedback, and there's no active training loop running today. It's a place mistakes get recorded, not a model that gets smarter on its own.

What it produced: 407 donors and 599 donation records for the Amar Ekushey Hall Unit, most of them entered as Telegram messages typed the way people already type, not through a form built assuming they'd type differently.

Parvej Shah is a Lead Full-Stack Web Developer & Platform Architect based in Dhaka, Bangladesh. Explore full architecture case studies and production code at parvejshah.com.

Self-Healing Chrome Extension: Building a DOM Injector That Fights Back

Parvej Shah — Wed, 26 Aug 2026 20:32:53 +0000

Originally published at parvejshah.com/blog/building-manifest-v3-ai-chrome-extensions by Parvej Shah.

LinkedIn's DOM Doesn't Just Drift

Most sites' markup drifts gradually over time. LinkedIn's is different: periodically, it ships builds where every semantic class name — feed-shared-update, social-actions-bar, all of it — is replaced with a short hashed token. Same page, same layout, but every selector you wrote against it stops matching overnight.

A content script that hardcodes selectors against a page you don't control is fragile by default. Against a page that occasionally scrambles its own class names on purpose, hardcoded selectors aren't just fragile — they're a losing strategy.

Building Something That Fixes Itself

Instead of chasing LinkedIn's markup by hand every time it changed, the extension eventually grew a self-healing layer: on load, it takes a snapshot of the feed DOM, sends it to an AI model, and asks for a fresh set of selectors.

The snapshot isn't a raw DOM dump. It's pruned aggressively — ads, nav, and sidebars stripped out, tag depth capped, children per node capped, long hashed class names filtered out, and any leaf text content run through PII stripping before being included. The whole thing is budgeted to stay under roughly 3,000 tokens serialized. That's a deliberate choice: sending less data isn't just cheaper, it also means the model isn't accidentally handed a stranger's post content to reason about.

The AI's job is narrow: look at this structural sketch of the page and return three CSS selectors — where posts live, where the post text is, where to inject a button — as JSON. That JSON becomes a "strategy," cached in `chrome.storage.local` and re-validated against the live DOM on every subsequent load before it's trusted again.

## The Fallback Chain

A single AI call is not something you want standing between a user and a working feature, so the actual flow on every page load is five steps deep:

javascript
// 1. Load cached strategy, validate against live DOM
// 2. If invalid/stale, regenerate via AI (rate-limited to 1 call / 30 min)
// 3. If AI unavailable or fails, fall back to a bank of hardcoded selectors
// 4. If that fails too, fall back to content.js's original 5-tier
// heuristic parser (text-content walking, data-view-name anchors)
// 5. Log every outcome to a rolling debug buffer for the popup's debug panel




The rate limit on AI regeneration (once per 30 minutes) exists because a validation failure loop without one would mean an AI call on every page load for every user whenever LinkedIn's DOM was in a bad state — expensive and pointless if the underlying cause won't resolve by calling again immediately.

## When LinkedIn Obfuscates on Purpose

The specific failure mode this was built for shows up as a distinct code path: an `isCorruptedDOM()` check looks for a feed marked with `data-view-name="feed-full-update"` but with none of the expected semantic classes present — the signature of an obfuscated build. When that's detected, the extension stops trying to match classes entirely and instead walks the DOM by structural role: `span[dir="ltr"]` elements tend to survive obfuscation intact, and a `TreeWalker` heuristic can still locate the action bar by matching visible text content ("Like", "Comment", "Repost") rather than any class name at all.

This is the part of the project I'm most proud of technically, and also the part that made it clear where the ceiling was. Text-content heuristics work until LinkedIn changes wording, adds another localization variant, or restructures the markup enough that even structural role stops being a reliable anchor. Every layer we added bought time, not permanence.

## Where It Ended Up

The extension is published and live on the Chrome Web Store today. But active development stopped after the self-healing system's last iteration. LinkedIn's anti-automation posture — DOM obfuscation, and behavior that reads as active bot detection rather than incidental markup churn — kept escalating faster than a side project could track, and at some point the honest call was to stop rather than keep building a more elaborate response to a page actively working against being scraped.

The lesson isn't "don't build content-script extensions." It's that self-healing buys real resilience against ordinary drift, but it doesn't change the fundamental asymmetry: the host page can always change faster than you can adapt, and eventually that stops being a technical problem you can architect your way out of.

---

*Parvej Shah is a Lead Full-Stack Web Developer & Platform Architect based in Dhaka, Bangladesh. Explore full architecture case studies and production code at [parvejshah.com](https://parvejshah.com).*

A Debouncer That Doesn't Scale Past One Worker (On Purpose, For Now)

Parvej Shah — Wed, 26 Aug 2026 20:31:58 +0000

Originally published at parvejshah.com/blog/conversational-commerce-webhook-architecture by Parvej Shah.

In Bangladesh and much of South and Southeast Asia, e-commerce doesn't look like what a Silicon Valley product manager pictures. Buyers don't browse a catalog and check out with a saved card. They send a message on Facebook or WhatsApp, ask if an item is in stock, negotiate slightly, confirm their address, and pay cash on delivery or by mobile banking transfer. The entire purchase funnel is a conversation.

SellerVai is built for exactly this reality — a sales agent that handles order inquiries across WhatsApp, Facebook Messenger, and Instagram, in Bengali and Banglish. The first engineering problem it has to solve isn't the AI. It's that customers don't send one message — they send four.

The Problem With Multi-Message Bursts

A real customer message looks less like a single query and more like this, sent as three separate texts twenty seconds apart:

"vai ei sneaker ta ki size 42 ache?"
"cash on delivery hobe?"
"dhaka te koto din lagbe?"

A webhook handler that reacts to each message independently fires three separate completions for what is, semantically, one question. The customer gets three overlapping replies instead of one coherent answer, and the token bill triples for no benefit.

The Debouncer, As It Actually Runs

SellerVai's fix is a per-conversation buffer that waits for a customer to actually finish typing before generating a reply — not a fixed delay, a quiet window. Every new message from the same conversation resets the timer; the buffered messages only get flushed to the agent once 7 seconds pass with nothing new arriving.

# Simplified from the real handler — one buffer per conversation ID,
# reset on every new message, flushed after 7.0s of silence.
class MessageDebouncer:
    def __init__(self, delay: float = 7.0):
        self.delay = delay
        self.buffers: dict[str, list[str]] = {}
        self.timers: dict[str, asyncio.TimerHandle] = {}

    async def add_message(self, conversation_id: str, text: str, on_flush):
        self.buffers.setdefault(conversation_id, []).append(text)
        if conversation_id in self.timers:
            self.timers[conversation_id].cancel()

        async def flush():
            messages = self.buffers.pop(conversation_id, [])
            self.timers.pop(conversation_id, None)
            await on_flush(conversation_id, "\n".join(messages))

        loop = asyncio.get_event_loop()
        self.timers[conversation_id] = loop.call_later(
            self.delay, lambda: asyncio.ensure_future(flush())
        )

Three messages in twenty seconds become one joined prompt, and the agent replies once.

Why In-Memory, Why Now

This buffer lives entirely in process memory, keyed by conversation ID — there's no Redis, no external store. That's a deliberate, scoped tradeoff, not an oversight, and the code says so directly: this design only works correctly with a single running worker. Run two workers behind a load balancer and a customer's messages could land on different processes, each with no idea the other is buffering the same conversation — the debounce would silently stop working.

For SellerVai's current traffic, one worker handling this path is genuinely fine — no infrastructure dependency, no network hop, no serialization cost, and a buffer that's trivial to reason about because it's just a dict. The migration path is already scoped for the day that stops being true: move the buffer and its timers into Redis, keyed the same way, so any worker can pick up any conversation. That's a known, deliberate future change, not a bug waiting to be found in production.

Async Without a Queue

The webhook handlers themselves don't push work onto a job queue — they hand off to FastAPI's BackgroundTasks, which runs the debounce-and-reply logic after the HTTP response has already gone back to Meta or Telegram. That buys simplicity: no queue to operate, no broker to keep alive, no separate worker deployment. What it doesn't buy is durability — a task that's in flight when the process restarts is gone, the same way the debounce buffer is. Both tradeoffs point the same direction: this is a single-process design, made once, applied consistently, not different pieces of the system quietly disagreeing about how much reliability they promise.

What We'd Tell the Next Team

Single-process-first isn't a shortcut you apologize for — it's a legitimate starting point when your actual load doesn't yet justify the operational cost of a queue and a distributed buffer. The mistake isn't choosing it. The mistake is choosing it silently, so nobody knows it's there until two workers get deployed and debouncing quietly breaks. Say it once, in the code, in plain language, and the tradeoff stops being a hidden bug and starts being a decision someone made on purpose.

Parvej Shah is a Lead Full-Stack Web Developer & Platform Architect based in Dhaka, Bangladesh. Explore full architecture case studies and production code at parvejshah.com.

What It Actually Takes to Build a Workforce Management Platform for an AI Company

Parvej Shah — Wed, 26 Aug 2026 20:31:54 +0000

Originally published at parvejshah.com/blog/engineering-precision-data-platforms-sft-rlhf by Parvej Shah.

The initial brief from GenMorphics AI Solutions sounded straightforward: build a dashboard to help their team coordinate work across a global network of domain experts. As we got into the details, "dashboard" turned out to be underselling it — this became a systems-architecture problem touching compliance, access control, and payroll as much as task management.

Skill-Scoped Task Routing

GenMorphics works with specialists across software engineering, mathematics, legal reasoning, and scientific writing. Routing doesn't try to auto-score someone's expertise — a specialist holds skills within categories, and eligibility for a task comes down to whether they hold the named skill in the required category.

The real design problem wasn't the matching logic — it was making the categories specific enough to mean something. "Knows Python" is close to useless as a routing signal. Splitting software engineering into language-specific tracks, and mathematics into calculus, linear algebra, and discrete math as separate categories rather than one "math" bucket, is what actually made routing reliable. The hard part of this system was taxonomy design, not algorithms.

Access Control as Data, Not Code

The platform serves people with fundamentally different access needs — domain experts who should see only their own tasks, project managers scoped to their own client portfolios, admins with full reach. Instead of hardcoding role checks scattered through the app, permissions live in the database: each role is a row with a set of resource.action.scope permissions — payment.read.own, nda.manage.all, and so on.

That decision paid off the first time GenMorphics needed a new role with a slightly different permission mix. It didn't need a deploy — it needed a database row. For an app that has to keep pace with how a growing team actually organizes itself, that flexibility mattered more than a marginally simpler hardcoded system would have.

Building an NDA Engine Instead of Buying One

Client task data — code, documents, domain material — can't reach a specialist until they've signed an NDA specific to that engagement. Rather than bolt on a third-party e-signature product, we built the NDA lifecycle inside the platform: a TipTap-based rich text editor with a custom node type for inserting recipient-specific variables into a legal template, template versioning so a signed document stays tied to the exact terms it was signed under, and a cryptographic hash of the final document for tamper-evidence.

Because NDA volume scales with contractor headcount, admins also needed to act on instances in bulk — voiding, expiring, counter-signing, reverting, or extending many at once rather than one dialog at a time. Building this in-house meant the NDA gate could be wired directly into task access instead of living as a disconnected compliance checkbox.

Payroll That Matches How the Org Actually Pays People

Payroll logic isn't one formula — it mirrors two different employment models in the same system. Operational roles (annotators, reviewers) are paid hourly against logged, effective time. Managerial roles are paid a fixed salary unless they have an hourly rate set, in which case hourly wins. Bonuses layer on top of either. None of this is generic timesheet-software logic — it's a direct encoding of how GenMorphics structures compensation across two different kinds of contributors.

What We Learned

The technical complexity here was never really about AI — it was a direct translation of how GenMorphics organizes people, compliance, and money. The skill taxonomy, the data-driven permission model, the in-house NDA engine, the dual payroll model — each one exists because encoding the org's actual structure mattered more than reaching for the nearest off-the-shelf pattern. A schema that's grown to 28 models across 61 migrations without a rewrite is really a record of that structure evolving over time, and the platform evolving with it.

Parvej Shah is a Lead Full-Stack Web Developer & Platform Architect based in Dhaka, Bangladesh. Explore full architecture case studies and production code at parvejshah.com.

AI Content Pipeline Safety: The Claims Gate That Stops Fabricated Customer Results

Parvej Shah — Wed, 26 Aug 2026 20:20:06 +0000

Originally published at parvejshah.com/blog/deterministic-multi-agent-systems-production by Parvej Shah.

The interesting engineering problem in an automated content pipeline for Minions.AI — a trade-contractor content engine — turned out not to be agent orchestration. It's not really about "researcher" and "writer" agents arguing in a loop, or a fragile hand-off protocol between them. The problem that actually mattered in production was narrower and more dangerous: stopping the pipeline from confidently publishing something false.

The Real Pipeline

Every draft moves through four Qwen (DashScope) model calls, each sized to what the stage actually needs rather than running a flagship model end to end:

Stage	Model	Why
Strategist	`qwen3.7-max`	Highest-leverage reasoning step — angle, audience fit, positioning. Errors here propagate through the whole draft, and the output is short, so flagship cost is negligible.
Writer	`qwen-plus`	Long-form generation (700–1000 words). Highest token volume of the four calls, so this is where cost tier matters most.
Editor	`qwen3.7-flash`	A bounded task — tighten prose, enforce style, and extract + classify every factual claim in the draft.
Variants	`qwen-flash`	Reformatting already-finished copy for LinkedIn and Facebook — no new reasoning needed.

This runs as an n8n workflow, not a hand-rolled orchestrator: a scheduled harvester proposes ideas twice a week, and a webhook-triggered pipeline runs each one through the four stages above, generates a hero image, uploads it to Cloudflare R2 before the image host's signed URL expires, and either publishes or gates the result.

The Claims Gate

The Editor stage doesn't just tighten prose — it extracts every factual claim in the draft and classifies it: STATISTIC, FACT, MARKET_CLAIM, PRODUCT_CLAIM, OPINION, or CUSTOMER_RESULT. Each claim then needs a source URL to pass.

One rule is hardcoded, not a judgment call: any claim classified CUSTOMER_RESULT is blocked outright. Not "flagged for review" — blocked. The reasoning is stated plainly in the pipeline's own documentation: the business has zero paying clients as of this writing, so any claim about a customer result would be fabricated by definition. There's no result to attribute yet, so the gate doesn't let the pipeline invent one.

Unsourced statistics, facts, and market claims are blocked too, unless they carry a real source URL. Opinion claims pass without a source — they're not verifiable by nature and aren't gate-relevant.

Enforcement, Not Just Reporting

The gate isn't a lint warning that a human can shrug off — it runs in two places:

Inline, during generation. If the claims gate doesn't pass, the asset skips straight past the auto-publish step instead of going live to the blog and Facebook Page.
Again in a separate review-publisher workflow, which polls the database every 5 minutes for anything a human has since approved manually in the review dashboard, and republishes it through the same gated path — so a claim can't sneak through by a human reviewer overriding the wrong field.

Either path leaves anything that isn't cleanly passed in a BLOCKED_PENDING_REVIEW state rather than live on the site.

What This Buys

This doesn't solve "AI agents coordinating AI agents" in some general sense — there's no elaborate retry protocol or critic-agent handshake here, and there doesn't need to be. It solves the one failure mode that actually matters for a marketing content pipeline running largely unattended: don't let the system say something happened for a customer when nothing has happened yet. Everything else — tone, structure, formatting — can be imperfect and get caught in review. A fabricated customer result is the one mistake that isn't safe to publish and fix later.

Parvej Shah is a Lead Full-Stack Web Developer & Platform Architect based in Dhaka, Bangladesh. Explore full architecture case studies and production code at parvejshah.com.

Rendering Math Formulas When Your Content Has Two Different Pasts

Parvej Shah — Wed, 26 Aug 2026 20:17:07 +0000

Originally published at parvejshah.com/blog/rendering-katex-formulas-nextjs-server-components by Parvej Shah.

MathPro Academy teaches JSC, SSC, and HSC mathematics to secondary students across Bangladesh. Formula rendering — quadratic formulas, trigonometric identities, the full range of secondary-school algebra — is not a cosmetic detail here; it's most of what the product actually shows a student.

What Build-Time Rendering Assumes

Pre-rendering LaTeX to HTML at build time (or on the server per-request, ahead of sending anything to the browser) works cleanly when content is fixed and known in advance. MathPro's content isn't: instructors edit course material continuously through the admin panel, and — because the platform migrated its editor from plain text to Lexical in December 2025 — the database holds a permanent mix of both formats side by side, not a one-time migration that finished and left a single clean shape behind.

An earlier version of this rendering path leaned toward doing more of that work ahead of time. It didn't hold up against that mix: a renderer that assumes one content shape breaks the moment it meets the other.

What Actually Ships

The real renderer, SafeHtmlRenderer, runs entirely client-side and does two jobs in sequence:

Format detection. It checks whether a record contains HTML tags. If not, it's legacy plain text — escaped and wrapped for consistent display. If it does, it's Lexical-authored HTML, sanitized through a fixed allowlist of tags and attributes before it ever touches the DOM.
LaTeX rendering. After the sanitized content mounts, a useEffect walks the container's text nodes looking for $...$ (inline) and $$...$$ (block) spans, and replaces each one with KaTeX-rendered markup — the same delimiter-matching logic the admin editor's own LaTeX plugin uses, so what an instructor sees while writing matches what a student sees while reading.

// Runs after mount, not on the server — the content it walks
// isn't known until the sanitized HTML is actually in the DOM.
useEffect(() => {
  if (processedContent?.type !== "html") return;
  renderLatexInElement(containerRef.current);
}, [processedContent]);

This is a real trade-off, not a free win: KaTeX ships to the browser, and rendering happens after mount rather than being baked into the HTML response. What it buys back is correctness across every record in the database, old and new, without a migration project or a format the renderer has to assume in advance.

The Sanitization Boundary Matters More Than the Renderer

The more interesting design decision isn't the KaTeX call — it's what happens before it. New content is run through a fixed allowlist of tags and attributes (DOMPurify) before dangerouslySetInnerHTML ever sees it. KaTeX's own markup is deliberately not pushed through that same sanitizer — its output relies on precise inline styles, MathML, and SVG that would need a much larger, riskier allowlist to preserve faithfully. Instead, KaTeX renders into the DOM directly, after the surrounding content has already been sanitized. Getting that boundary right — sanitize the untrusted parts, trust the library you control — is the part of this that would have been easy to get wrong.

What We'd Tell the Next Team Doing This

If your content has one shape and it's fixed at build time, server-side pre-rendering is the better call — no argument. But "server-side" isn't automatically the more sophisticated choice. When the actual constraint is "the data has two generations mixed together and keeps changing," a runtime renderer that normalizes format first and renders second is the simpler, more honest design — even though it costs a client-side bundle and a post-mount pass that a cleaner dataset wouldn't need.

Parvej Shah is a Lead Full-Stack Web Developer & Platform Architect based in Dhaka, Bangladesh. Explore full architecture case studies and production code at parvejshah.com.