DEV Community: Sharik Wani

Most Real-Time Platforms Don't Fail From Scale. They Fail From Ambiguity

Sharik Wani — Wed, 22 Apr 2026 16:29:51 +0000

A lot of engineering teams spend time preparing for scale before they prepare for ambiguity.

That sounds backward at first, but in practice ambiguity is what breaks many real-time systems long before traffic does.

Not infrastructure ambiguity. Operational ambiguity.

The kind that shows up when a system technically works, but nobody can clearly answer basic questions like:

What state is this request in right now?
Why was this user routed here?
What happens if the assigned expert never responds?
What does the user see when the workflow falls into an edge case?
Can support, engineering, and operations all explain the same event in the same way?

When teams cannot answer those questions consistently, reliability starts eroding even if uptime still looks good.

The hidden cost of unclear system state

One of the most common mistakes in platform engineering is assuming that responsiveness and reliability are the same thing.

They are not.

A system can be fast and still be confusing.
A system can be available and still be hard to trust.
A workflow can technically complete and still leave the user unsure about what just happened.

That is especially true in platforms built around live interaction, expert access, service coordination, or real-time response. In these systems, the user is not just waiting for data. They are waiting for clarity.

That changes how the product should be engineered.

If a request is created, assigned, reassigned, escalated, paused, resumed, and resolved, each of those transitions must be explicit. Not only in the backend, but in the product behavior as well.

Teams that skip that discipline usually end up in a familiar situation: support is interpreting one version of the workflow, engineering is logging another, and the user is seeing a third.

That is when things start to feel unreliable.

"Works in the happy path" is not a systems strategy

Many real-time systems look strong in demos because the happy path is smooth.

A user submits a request. A match is found. A response arrives. Everything looks clean.

But the real quality of the platform is usually revealed in less convenient moments:

No suitable expert is immediately available
The selected expert declines the request
A user changes categories mid-session
The request contains mixed intent
A connection drops during the conversation
The system needs to hand the case off without losing context

That is the difference between building a feature and building an operating system for trust.

The first version of a platform often assumes that state transitions are obvious. They rarely are. Every state that is not formally modeled turns into a future support problem.

A simple example:

from enum import Enum

class RequestState(str, Enum):
    CREATED = "created"
    TRIAGED = "triaged"
    ASSIGNED = "assigned"
    IN_PROGRESS = "in_progress"
    WAITING_ON_USER = "waiting_on_user"
    REASSIGNED = "reassigned"
    RESOLVED = "resolved"
    FAILED = "failed"

This is basic, but it makes an important point. Systems become easier to reason about when important transitions are named, constrained, and visible.

Without that, teams end up relying on tribal knowledge and interpretation.

Reliability is a product experience, not just an infrastructure metric

A lot of engineering organizations still talk about reliability almost entirely in terms of uptime, latency, and incident count. Those are necessary signals, but they are incomplete.

For user-facing platforms, reliability is also shaped by:

Whether the product explains delays clearly
Whether fallback paths are understandable
Whether users lose context during reassignment
Whether the system recovers gracefully from interruption
Whether support teams can reconstruct what happened

The reason this matters is simple: trust is not only damaged by outages. It is damaged by confusion.

Users do not experience reliability as a graph in an ops dashboard. They experience it as a feeling:

"I understand what is happening."
"The platform is still in control."
"I know what happens next."
"My time is not being wasted."

Good systems create that feeling deliberately.

Observability should answer product questions, not just infrastructure questions

This is another place where mature systems separate themselves from early-stage ones.

A lot of teams instrument their infrastructure well but under-instrument their workflow.

They know CPU utilization. They know queue depth. They know request volume.

But they do not know:

How often requests are reassigned
Where users abandon the workflow
How long requests stay in unresolved intermediate states
Which categories have the highest routing uncertainty
Where trust breaks before resolution breaks

Those are not "nice to have" metrics. They are the signals that actually tell you whether the system is behaving well.

If I were evaluating a real-time expert platform, I would want to see metrics like:

Request-to-assignment time
Time to first meaningful response
Reassignment frequency
Unresolved session rate
Silent timeout rate
Category-level satisfaction
Recovery success after interruption

Those numbers reveal much more than raw throughput.

The routing layer is often the real product

In platforms that connect users with specialists, advisors, support professionals, or subject-matter experts, the routing layer is not just backend plumbing. It is one of the most important parts of the product.

The user does not care whether the routing system is elegant. They care whether it gets them to the right person quickly and consistently.

That usually means simple keyword logic is not enough.

Real systems often need to balance:

Topic confidence
Availability
Expertise match
Language fit
Workload
Urgency
Escalation priority
Regulatory or geographic constraints

A rough scoring sketch might look like this:

def score_route(match_confidence, availability, workload, priority):
    return (
        match_confidence * 0.5
        + availability * 0.25
        - workload * 0.15
        + priority * 0.10
    )

Obviously real implementations are more involved, but the principle matters. Routing is usually a weighted decision problem, not a yes-or-no rule.

And once that routing begins influencing trust, resolution quality, and retention, it stops being "just backend logic." It becomes a core business capability.

Calm systems win

One of the most underrated product qualities in engineering is calmness.

Strong systems do not just feel fast. They feel composed.

They tell users what is happening.
They degrade gracefully.
They make edge cases understandable.
They preserve context.
They avoid surprising people.

That takes discipline across architecture, product design, and operations.

In my experience, the most impressive platforms are not the ones with the loudest features. They are the ones where complexity is handled so well that the user barely notices it exists.

That is a much harder engineering challenge.

Where this thinking comes from

These are not theoretical observations. They come from building HelpByExperts, a platform that connects users with verified professionals for $3 per consultation across 15 categories including plumbing, electrical, career coaching, auto mechanics, and home repair.

Every problem described above — state ambiguity, routing quality, trust design, edge case recovery — is something we deal with in production. Our AI assistant handles intake and routing. Real credentialed experts, verified through government licensing registries, provide the actual advice. The routing layer, state management, and observability are what make the difference between a $3 consultation that feels cheap and one that feels worth ten times that.

If you are building anything similar — expert marketplaces, consultation platforms, real-time service coordination — I would love to compare notes in the comments.

What It Actually Takes to Build a Reliable Real-Time Expert Platform published.

Sharik Wani — Fri, 17 Apr 2026 06:56:36 +0000

There is a big difference between building a website that looks polished and building a platform that people trust when they need real help.

A lot of software products work well when the stakes are low. If a dashboard loads slowly or a background task finishes late, most users will never think twice about it. But when you are building a platform that connects users with real experts in areas like legal support, technical troubleshooting, home services, or urgent guidance, the engineering standard changes completely.

At that point, you are no longer just shipping features. You are designing for trust, response time, reliability, and operational clarity.

That is where the real work starts.

The architecture problem nobody talks about enough

Most teams initially think this kind of system is just a marketplace with chat. In practice, it is a coordination problem with strict reliability expectations.

You have to handle:

User intent classification
Expert routing and matching
Real-time communication
Identity and credential verification
Queue balancing under load
Failure recovery mid-conversation
Moderation and auditability
Secure data handling
Asynchronous follow-up flows

The challenge is not any single part. The challenge is that all of them interact.

For example, if your expert assignment logic is fast but weak, users get connected quickly but to the wrong person. If your verification system is strong but slow, you create trust at the cost of usability. If your messaging works but state synchronization is messy, support quality collapses the moment a conversation moves between systems.

This is why these platforms are hard to get right.

Speed without correctness is expensive

A mistake I have seen repeatedly is optimizing early for visible speed while ignoring matching quality.

Teams often celebrate low response times before they validate that the system is routing requests correctly. But from a product perspective, a fast wrong answer is often worse than a slightly slower correct one.

A production-grade routing layer usually needs more than simple keyword matching. In most real systems, you need a weighted combination of category confidence, expert availability, language preference, urgency signals, geographic constraints, historical performance, current load, and escalation rules.

A simplified version of expert scoring might look like this:

from dataclasses import dataclass

@dataclass
class Expert:
    id: str
    specialties: set[str]
    is_online: bool
    rating: float
    active_sessions: int
    languages: set[str]

def score_expert(expert: Expert, topic: str, language: str) -> float:
    score = 0.0
    if topic in expert.specialties:
        score += 50
    if language in expert.languages:
        score += 20
    if expert.is_online:
        score += 15
    score += min(expert.rating * 2, 10)
    score -= expert.active_sessions * 3
    return score

Nobody should mistake this for a production routing engine, but it illustrates the point: expert matching is usually a scoring problem, not a binary rules problem.

And once you introduce real traffic, you quickly learn that routing logic must be observable. If your team cannot explain why a user was matched to a specific expert, debugging quality issues becomes painful.

Reliability is not just uptime

A lot of engineering teams still reduce reliability to infrastructure uptime. That is only one layer.

For platforms that depend on expert interaction, reliability also means:

Can the right expert be reached at the right time?
Can the conversation recover after interruption?
Can the system preserve context across retries?
Can the user understand what is happening when no expert is immediately available?
Can the team audit what happened after the fact?

In these systems, trust is often lost in edge cases rather than outages.

A few examples of where trust breaks down:

A user submits a request and gets no useful status update for several minutes.
A conversation is handed off but prior context is lost, so the user has to repeat everything.
An expert goes offline mid-session and the system does not reassign or notify the user.
A payment is taken but no session ever starts due to a routing failure.

None of these are "down" scenarios. The system is technically up. But the user experience is broken, and trust is lost.

Operational visibility should be designed early

Most teams underinvest in observability until something goes wrong in production. But for expert platforms, operational clarity is a first-class product requirement.

At a minimum, you need:

Real-time tracking of active sessions, queue depth, and expert availability
Alerting on matching failures, timeout thresholds, and dead-letter queues
A full audit trail of every conversation: who was matched, when, what was said, how it was resolved
Performance dashboards showing response time distributions, not just averages

The reason averages are dangerous: if your average response time is 90 seconds but your p95 is 8 minutes, you have a serious problem that the average completely hides. Those p95 users are your most frustrated users, and they are the ones who leave bad reviews and request refunds.

The hardest engineering work is often product-shaped

The trickiest problems in building expert platforms are rarely pure infrastructure. They are at the intersection of product decisions and engineering constraints.

Questions like:

What happens when no expert is available in a category? Do you queue, redirect, or refund?
How do you handle a user who pays but then abandons the session before an expert responds?
When should the system auto-escalate a conversation to a more senior expert?
How do you measure expert quality without creating perverse incentives?
What is the right balance between AI-assisted intake and human judgment?

These are not coding problems. They are design problems that require engineering to implement correctly. And getting them wrong creates user experience failures that no amount of scaling can fix.

What I learned building this

I have been working on HelpByExperts, a platform that connects users with verified professionals for $3 per consultation across 15 categories including plumbing, electrical, career coaching, auto mechanics, and home repair.

The stack is Next.js 14 on Vercel, Supabase for auth and database, Stripe for payments, and OpenAI for the AI intake assistant (Ava). The expert verification uses government licensing registries — each expert's credentials are independently verifiable through official bodies like Skilled Trades Ontario.

A few things I have learned that I wish I had known earlier:

Credential verification is harder than it sounds. We initially planned to verify experts through self-reported credentials. That turned out to be useless for trust. We ended up requiring government-issued license numbers that users can independently verify on official registries. This dramatically increased trust but also dramatically reduced the pool of experts willing to go through the process.

AI intake is extremely valuable but must know its limits. Our AI assistant Ava handles initial routing and question gathering. This makes the process fast and available 24/7. But we had to build clear handoff points where the AI explicitly says "here is what I have gathered, now let me connect you with the expert" rather than trying to answer the question itself.

Payment timing matters more than you think. We experimented with payment before chat, payment after chat, and payment at the "proceed to expert" moment. The last option performed best by a significant margin because the user has already invested time describing their problem and seen the AI acknowledge it.

The $3 price point is a product decision, not just a business decision. At $3, the refund rate is very low because the stakes are low. Users are more willing to try the service, and experts can serve more users per hour because there is less pressure to justify a high fee. The unit economics work because AI handles intake and routing, eliminating the overhead that makes traditional consultations expensive.

Final thought

If you are building any kind of expert marketplace or consultation platform, invest heavily in three things early: matching quality (not just speed), operational observability, and credential verification. Everything else — UI polish, marketing, pricing experiments — is easier to iterate on later. Those three foundations are extremely expensive to retrofit.

If you want to see how this works in practice, you can try HelpByExperts or check out the expert profiles to see how credential verification looks from the user side. Happy to answer questions in the comments.