Forem: Vishal Koriya

The moment you realize users don’t follow your flow

Vishal Koriya — Thu, 30 Apr 2026 04:40:29 +0000

We designed a clean flow.

Step 1 → Step 2 → Step 3
Everything validated
Everything controlled

Looked perfect.

Then users showed up.

They skipped steps
Went back and edited things
Opened multiple tabs
Triggered the same action twice

Nothing crashed.

But data started breaking:
Incomplete records
Duplicate entries
Out of order updates

Problem was not the code.

Problem was the assumption:
Users will follow the flow.

They don’t.

Fix was not adding more UI restrictions.

We changed the backend:
Every step validates current state
Actions become idempotent
Order of execution is not trusted
System accepts messy input and still produces a correct result

Real systems are not linear.

They are chaotic.

This comes up a lot in BrainPack deployments. You are not designing flows for ideal users, you are building systems that survive real behavior.

You are not building features. You are controlling outcomes

Vishal Koriya — Wed, 29 Apr 2026 04:39:28 +0000

Early on, I thought my job was to build features.

New endpoint
New button
New flow

Ship it and move on.

That works until the system starts doing real work.

A single action is never just one thing:
Create order
Update inventory
Trigger invoice
Notify someone

Now add retries, partial failures, and inconsistent data.

You realize quickly:
The feature is not the outcome.

The outcome is:
Was the order created correctly
Is inventory accurate
Did the right person get notified
Can we trust the system state after all this

Most of the time, the code “works”.

But the outcome is wrong.

That is where the real work starts.

We started changing how we build:

Every action is tracked end to end
Each step is validated before moving forward
Failures are handled explicitly, not ignored
State is checked across systems, not assumed

Less focus on adding features.

More focus on controlling what actually happens after they run.

Because in real systems, users do not care what you built.

They care if the result is correct.

This is how we approach systems at BrainPack. The goal is not to ship features, but to make sure every action across connected systems leads to a predictable and correct outcome.

You don’t need a new ERP. You need control over the one you have

Vishal Koriya — Tue, 28 Apr 2026 04:13:12 +0000

Most systems are not the problem.
Lack of control is.
We have seen companies running:
ERP
Spreadsheets
Email workflows
Custom tools

Everything exists. Nothing works together.

So the first instinct is:
Let’s replace the ERP.

That usually turns into a long cycle:
Migration planning
Data cleanup
Vendor coordination
Months of partial rollout

And during all this, the business still runs on the same broken flows.

We take a different approach.
Instead of replacing the system:
Connect it to the rest of the stack
Add missing workflows on top
Fix how data moves between systems
Control execution from one layer

In one case, order flow was split across ERP and manual Excel tracking.

We did not replace anything.

We added:

A layer to capture orders from all sources
Validation before pushing into ERP
Sync logic to keep both sides consistent

Same ERP. Different behavior.
Most systems fail because they are isolated, not because they are outdated.

Once you control how systems talk and execute, the need to replace them drops a lot.

This is what we deal with in BrainPack deployments every day. The goal is not to remove existing systems, but to make them work together in a way the business can rely on.

AI was slow. The problem wasn’t the model.

Vishal Koriya — Mon, 27 Apr 2026 04:39:16 +0000

AI responses were taking 6 to 8 seconds. Not the model. Data fetching.

Flow was fully sequential:
CRM
Inventory
Accounting
Then build response

Each question was starting from zero.

Same data. Same queries. Repeated every time.

Fix was simple. Stop fetching everything again and again.

We changed how context is handled.

Instead of fetching on every request:

Preload frequently used data when session starts
Store it in session context
Reuse it across multiple questions

So the second and third question do not hit all systems again.

Problems we hit:

Stale data
Some values changed during the session
Fixed by adding expiry on cached context
Memory growth
Session context kept increasing
Fixed by limiting what we store and cleaning unused data

Result:
6 to 8 seconds down to around 3 seconds average
Follow up queries became much faster

AI did not get faster. We just stopped wasting time fetching the same data.

This is the kind of problem that shows up in BrainPack deployments where AI depends on multiple existing systems. The bottleneck is almost always in how data is orchestrated, not the model.

The hardest part of adding AI on top of business systems isn’t the model. It’s making it work safely in production.

Vishal Koriya — Thu, 23 Apr 2026 15:45:46 +0000

Everyone focuses on prompts and accuracy.
But once AI connects to real systems, things change.

Now it’s not just answering.

It’s:
reading actual business data,
triggering real actions,
working across different tools.

“Show revenue” is not just a query.
It depends on who’s asking.
“Create order” is not just a command.
It needs validation before execution.

This is where most demos stop.
And real systems start.

What we are building is not just AI responses.
It’s a layer that:

understands context,
respects access,
executes correctly.

AI on top of systems works.
But only when you treat it like infrastructure, not a feature.

That’s the difference.