DEV Community: Parvej Shah

The Product Behind the Viral Map

Parvej Shah — Tue, 06 Oct 2026 14:24:35 +0000

Originally published at parvejshah.com/blog/the-product-behind-the-viral-map by Parvej Shah.

We talk a lot about Product-Market Fit.

But Unseen Bangladesh made me think about something else.

The product didn't go viral. The content it created did.

If you're reading this from outside Bangladesh, here's the context.

Bangladesh is divided into 64 districts across 8 administrative divisions. For many Bangladeshis, travelling across these districts is a personal record of where they've been, what they've seen, and what parts of the country they still haven't explored.

Unseen Bangladesh is a travel-focused web platform built around that idea.

Its most talked-about feature is surprisingly simple: select the districts you've visited, choose a visual theme, optionally add your name and photo, and generate a personalized map showing your travel history. The map can then be downloaded as an image or PDF and shared.

The platform itself goes beyond this feature. It also includes travel guides for Bangladesh's districts, a trip planner, quizzes, a map puzzle and a leaderboard. But in early October 2026, it was the personalized travel map that started spreading across Bangladeshi social media.

The creator, Md. Sabbir Hossain Robin, describes the project as something he originally built out of personal interest. He enjoys travelling and came up with the idea while trying to create a map of the places he had visited himself.

That origin story is interesting.

But what really caught my attention wasn't the story behind the product.

It was the distribution loop hidden inside the product itself.

The product didn't go viral. The content did.

Think about what normally happens when you use a product.

You open it.

You do something.

You get a result.

And then you leave.

Unseen Bangladesh changes the last part.

You don't just use the product and receive information.

You create something that represents you.

That distinction matters.

When someone selects 23 out of Bangladesh's 64 districts, the resulting map isn't just a functional output.

It says:

"These are the places I've been."

Someone else sees that map in their Facebook feed and immediately has a reason to interact with it:

"How many have I visited?"

So they open the website, create their own map, and share it.

Now their friends see it.

And the cycle repeats.

That's a very different growth mechanism from simply putting a "Share" button on a product.

The viral loop was inside the product

The basic interaction is almost embarrassingly simple:

Select → Customize → Generate → Share

But look at what happens after that:

Use the product

↓

Create a personal artifact

↓

Share it

↓

Someone else sees it

↓

They compare themselves

↓

They want their own map

↓

They use the product

The user-generated artifact becomes the distribution channel.

That is the part I find most interesting from a product engineering perspective.

This is where I started thinking about Product-Content Fit

Product-Market Fit asks:

"Do people want this product?"

I think there is another question worth asking:

"Does using this product naturally produce something people want to share?"

I'm calling that Product-Content Fit.

I'm not presenting it as an established industry framework. It's simply the term I use for a product property I noticed while looking at Unseen Bangladesh.

The distinction is useful.

A product can have strong Product-Market Fit without producing anything shareable.

For example, imagine a great accounting application. Businesses may desperately need it. They may use it every day. They may pay for it for years.

But nobody is likely to post:

"Look at my beautifully reconciled balance sheet."

The product can be valuable without being socially distributable.

Unseen Bangladesh is different.

The output is inherently personal.

And personal things are often much easier to share.

People don't share products. They share themselves.

This might be the most important part.

People aren't necessarily sharing Unseen Bangladesh because they want to promote Unseen Bangladesh.

They're sharing their own map.

The product is almost invisible in the final social interaction.

What appears in the feed is:

where I have travelled
how much of Bangladesh I have explored
which districts I haven't visited
what my travel history looks like

The product turns personal data into a small social artifact.

And that changes the motivation to share.

You're not saying:

"Check out this website."

You're saying:

"This is me."

That is a much stronger reason to post something.

The output matters as much as the interface

As software engineers, we spend a lot of time thinking about interfaces.

Buttons.

Forms.

Loading states.

Navigation.

APIs.

Databases.

Performance.

But sometimes the most important product decision happens after the main interaction is finished.

What does the user leave with?

In this case, the answer isn't simply "a result."

They leave with a visual representation of themselves.

That makes the output part of the product experience.

And more importantly, it makes the output part of the distribution system.

This leads to a principle I've started thinking about:

Don't just design the share action. Design the thing worth sharing.

A share button is a feature.

A shareable artifact is a product decision.

The friction was also unusually low

The map doesn't ask users to learn a complicated system.

The core flow is straightforward:

Select the districts you've visited.
Choose a visual theme.
Optionally personalize the map.
Download it.

The site supports PNG, JPG and PDF downloads.

That matters because every additional step between "I want to try this" and "I have something I can share" creates another opportunity for the user to disappear.

The product gets out of the way.

The interesting part is the result.

The creator didn't need to start with a growth strategy

There is another lesson here that I find even more interesting.

According to the site's own description, the idea started as a personal hobby. The creator wanted to map his own travels around Bangladesh and built something for people who share that interest.

There is no guarantee that a hobby project will become popular.

But building something personally meaningful can lead to a very useful product property:

You understand why someone would care about the output.

That's difficult to manufacture through growth tactics alone.

You can add referral systems.

You can add social sharing.

You can add notifications.

You can add a "Share with friends" button.

But if the thing being shared isn't interesting, none of those features solve the underlying problem.

The deeper product engineering lesson

When I build or think about products, I usually ask:

What does the user do?

I'm starting to think we should ask another question:

What does the user produce?

And then one more:

What happens to that output after the user leaves the product?

For Unseen Bangladesh, the answer is powerful.

The user produces a personalized travel map.

That map leaves the product.

It enters Facebook.

Someone else sees it.

That person becomes a potential user.

So the product's output doesn't stop at the application boundary.

It travels.

That's a product engineering consideration, not just a marketing consideration.

Product-Market Fit vs Product-Content Fit

I don't think Product-Content Fit replaces Product-Market Fit.

They're answering different questions.

	Product-Market Fit	Product-Content Fit
Core question	Do people want the product?	Does using it create something worth sharing?
Focus	User demand	User-generated output
Value	Product solves a problem	Output creates social interest
Distribution	Usually requires a separate channel	The output can become the channel
Example	A useful accounting platform	A personalized travel map

The strongest products can potentially have both.

People want the product.

And using the product naturally creates something that attracts more people.

What I would take from Unseen Bangladesh

I'm not taking away the lesson that every product should try to become viral.

Most products shouldn't.

And "make it shareable" is not a strategy by itself.

The more interesting lesson is this:

Think about the artifact your product creates.

Could it represent the user?

Could it help them express an identity?

Could it make their progress visible?

Could it give them something interesting to compare?

Could they be proud of it?

Could they show it to someone else?

If the answer is yes, your product may have a distribution mechanism hiding inside the user experience.

That's what I saw in Unseen Bangladesh.

A simple travel map became a social artifact.

The social artifact became content.

The content became distribution.

And the distribution brought people back to the product.

That's why I think the more interesting question isn't only:

"Do people want this?"

It's also:

"Does using this give people something worth sharing?"

Maybe that's another dimension of product thinking worth paying attention to.

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.

Before Building a Real Estate Voice Agent, I Needed to Understand the Calls

Parvej Shah — Tue, 22 Sep 2026 05:08:33 +0000

Originally published at parvejshah.com/blog/before-building-real-estate-voice-agent-understanding-calls by Parvej Shah.

I've been spending more time thinking about AI voice agents for real estate.

At first, the product seemed fairly straightforward. A lead calls about a property. The AI answers, asks a few questions, qualifies the lead, checks availability, and hopefully books a showing.

Technically, we can build that. But the more I looked at it, the more I realized I was starting with the wrong question.

I was asking: "How do we build the voice agent?"

Before answering a much more important one: "What is a good real estate agent actually trying to accomplish during this call?"

That distinction changes almost everything.

The technology is becoming the easy part

Building a voice agent today is surprisingly accessible. We can connect a phone number, speech models, an LLM, a CRM, calendars and other tools. We can make the system answer questions, collect information, and trigger actions.

So it becomes tempting to think of the workflow as:

Call → AI → Appointment

Nice and clean. Except the actual conversation between those three boxes contains most of the business logic.

Someone might call about a specific property. Someone else might only know their budget and preferred neighborhood. One caller might be ready to tour this weekend. Another might not have financing sorted out. Another might be selling their current home first. Someone else may simply have a question that requires a human agent.

Those aren't the same conversation.

And the data reinforces how important this early interaction is. Zillow's 2025 research found that 52% of successful buyers said contacting a real estate agent was their first home-buying activity, and 80% had contacted one within their first three activities. A private in-person tour was also a common next step. [1]

So the conversation isn't some minor administrative step sitting on the edge of the buying process. It can be near the beginning of the relationship.

A booked showing isn't always the goal

This was another assumption I had to challenge.

It would be convenient to measure a voice agent like this:

More calls → more booked showings → better agent.

But that's too simplistic. A successful call might end with a showing booked, a qualified lead captured, a question answered, a follow-up scheduled, or a handoff to the right human. The system needs to understand which outcome makes sense.

That's especially important because people don't all want to communicate the same way. Zillow's 2025 survey of prospective U.S. buyers found phone calls were the preferred method for 33%, while SMS was preferred by 34% — and preferences varied considerably by age. [2]

A voice agent therefore shouldn't necessarily try to keep someone on the phone until it achieves its own definition of "conversion." Sometimes the best outcome of the call might be "I'll text you those details." Sometimes it's "let me connect you with the agent." And sometimes it's "I can schedule that showing."

That's a much more interesting system to design.

The `???` is becoming the important part

The mental model I started with looked like this:

Incoming call → AI → Showing

Now I think about it more like:

Incoming call → understand intent → gather relevant context → determine next action → execute or escalate

The AI is only one component inside that flow. And suddenly the questions I'm interested in aren't primarily about models.

What information does an agent need before arranging a showing? Which questions should be asked, and in what order? When should the AI stop asking questions? What should happen when someone doesn't know their financing situation? What happens when the caller asks something the system shouldn't answer confidently? When does a human need to take over?

Those questions require understanding real estate, not just understanding LLMs. That matters because human agents still do much more than provide property information. The National Association of Realtors' 2025 U.S. buyer and seller research found that 88% of buyers purchased through an agent or broker. Buyers particularly sought help finding homes, negotiating terms, and navigating paperwork. [3]

AI doesn't make that complexity disappear. It has to operate inside it.

Maybe "human-like" is the wrong benchmark

A lot of voice AI demos focus on how natural the system sounds. Latency is tiny. It interrupts naturally. It says "um." You can barely tell it's AI.

Those are impressive engineering achievements. But for a business, I think there's another benchmark that matters more:

Did the conversation move the customer toward the correct next step?

An incredibly human-sounding agent that qualifies the wrong person, invents an answer, or pushes every caller toward an appointment isn't a good system. Meanwhile, a slightly less magical voice experience that correctly understands intent, retrieves reliable information, captures context, and knows when to hand over to a human may create much more value.

That changes what "good" means.

Domain knowledge becomes part of the engineering

There's a broader lesson here that goes beyond real estate. As AI makes implementation easier, understanding what should be implemented becomes more valuable.

A developer can learn a voice platform, its APIs, how to connect tools, how to improve prompts. But none of those automatically teach us how a brokerage operates.

That's why, before trying to build the perfect real estate voice agent, I'm becoming more interested in the calls themselves. What do great agents ask? What do buyers ask repeatedly? Where does a conversation change direction? What information actually affects the next action? Where do leads disappear? Where should automation stop?

I'm still researching those questions. And I think that's exactly the point.

The goal isn't to build an AI that sounds like a real estate agent. It's to understand what a good real estate conversation accomplishes, then decide which parts AI should handle.

The technology can answer the phone. The real work starts after hello.

Sources: Zillow Consumer Housing Trends Report 2025 — Buyers, Zillow Consumer Housing Trends Report 2025 — Prospective Buyers, NAR 2025 Profile of Home Buyers and Sellers

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.

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.

DEV Community: Parvej Shah

The Product Behind the Viral Map

The product didn't go viral. The content did.

The viral loop was inside the product

This is where I started thinking about Product-Content Fit

People don't share products. They share themselves.

The output matters as much as the interface

The friction was also unusually low

The creator didn't need to start with a growth strategy

The deeper product engineering lesson

Product-Market Fit vs Product-Content Fit

What I would take from Unseen Bangladesh

Before Building a Real Estate Voice Agent, I Needed to Understand the Calls

The technology is becoming the easy part

A booked showing isn't always the goal

The ??? is becoming the important part

Maybe "human-like" is the wrong benchmark

Domain knowledge becomes part of the engineering

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

We optimized the developer's side of software

Rapid prototyping was never meant to mean "build more"

The rising UX bar: "Good enough" is moving

What makes rapidly built software actually usable?

The bottleneck is moving

Why Browser Agents Fail in Production Without Semantic Layers

The Fragility of Machine Vision in Modern DOMs

Moving Beyond Ephemeral Selectors

Machine Intent as a First-Class Frontend Concern

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

What "Boring Technology" Means in Practice

The Real Velocity Driver: Short Feedback Loops

Knowing What to Leave Out

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

The Instinctive Wrong Move

The Actual Split on This Portfolio

Static Generation with Database Content

One Actual Gotcha

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

Why a Structured ID Beats a Cryptographic Scheme

Payment-Gated, Not Module-Gated (Yet)

Tuition That Matches How Executive Programs Actually Get Paid

Materials Are Private Because They're Never Public

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

What We Learned

Streaks Without Race Conditions: What Actually Runs Behind Codervai CP

Publishing, Not Pacing

The Streak Concurrency Problem

Video: Buy, Don't Build

What Held Up, What Didn't

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

The Bottleneck Wasn't Search, It Was Entry

Path One: Telegram, No AI Involved

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

Fallback Isn't Optional

What This Buys, and What It Doesn't

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

LinkedIn's DOM Doesn't Just Drift

Building Something That Fixes Itself

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

The Problem With Multi-Message Bursts

The Debouncer, As It Actually Runs

Why In-Memory, Why Now

Async Without a Queue

What We'd Tell the Next Team

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

Skill-Scoped Task Routing

Access Control as Data, Not Code

Building an NDA Engine Instead of Buying One

Payroll That Matches How the Org Actually Pays People

What We Learned

The `???` is becoming the important part