DEV Community: Dhruvi

What Documentation Looks Like in a Permanently Operated System

Dhruvi — Thu, 04 Jun 2026 12:39:15 +0000

I used to think documentation was mostly for onboarding.

A way to help new developers understand the system.

That's part of it.

But when you're operating systems continuously, documentation becomes something else entirely.

It's operational infrastructure.

The biggest misconception about documentation is that it's about explaining how things were built.

Most of the time, that's not what people need.

What they need is:

how does this actually work today?
what happens if it fails?
who depends on it?
what should happen next?

One thing I learned pretty quickly:

Nobody reads long documentation during an incident.

If something breaks, people need answers fast.

So the most useful documentation is usually the simplest.

Things like:

workflow diagrams
system dependencies
retry behavior
recovery steps
known failure points

Another thing that changes in long-running systems:

Documentation can't be static.

The system evolves.

Integrations change.

Business processes change.

Automations get added.

If documentation doesn't evolve too, it slowly becomes misleading.

And outdated documentation is often worse than no documentation at all.

The documentation I use most is rarely technical.

It's operational.

Questions like:

Why does this process exist?

What happens if this service is unavailable?

Which systems depend on this workflow?

Those answers save more time than implementation details.

One thing I appreciate now:

Good documentation reduces dependency on specific people.

Without it, knowledge gets trapped.

One person knows how something works.

One person knows how to recover it.

One person knows why it was built that way.

That's a risk.

In systems that run continuously, documentation is less about explaining code and more about preserving operational knowledge.

Because eventually, everyone forgets why a decision was made.

The documentation is what remains.

At BrainPack, a lot of the systems we operate involve multiple integrations, workflows, and AI layers running together. Good documentation helps turn individual knowledge into infrastructure that the entire team can rely on over time.I used to think documentation was mostly for onboarding.

What Building Software That Runs 24/7 Actually Means Day to Day

Dhruvi — Wed, 03 Jun 2026 13:04:16 +0000

When people hear that a system runs 24/7, they usually think about uptime.

Servers running.

Services responding.

No outages.

But day to day, that's not what I spend most of my time thinking about.

What I actually think about is:

What happens at 2:13 AM when something unexpected occurs?

Because eventually, it will.

A queue gets stuck.

A third party API slows down.

A workflow starts behaving differently.

A retry arrives hours later than expected.

The interesting part is that most problems aren't dramatic.

The system doesn't crash.

It keeps running.

Just slightly wrong.

And those are often the hardest issues to catch.

Building software that runs continuously means caring about things that demos never show:

recovery
observability
retries
data consistency
failure handling

Not because they're exciting.

Because they become important every single day.

One thing I learned pretty quickly:

The goal isn't building a system that never fails.

The goal is building a system that can recover without someone jumping in every time.

If a process gets stuck, can it restart?

If an API fails, can it retry safely?

If data arrives late, can the workflow still complete correctly?

Those questions matter more than most features.

Another reality is that software running 24/7 creates a different relationship with technical decisions.

Small shortcuts last a long time.

Small bugs eventually surface.

Small assumptions eventually get tested.

The system has a lot of time to find weaknesses.

What surprised me most is how much of the work is actually about predictability.

Not speed.

Not new features.

Predictability.

Knowing how the system behaves when things go right and when they don't.

Because people eventually start depending on that behavior.

Building software that runs continuously has changed how I think about engineering. The feature is only the beginning. The real work starts when the system has to keep doing its job reliably every hour of every day.

This is the reality of a lot of the systems we operate at BrainPack. Once enterprise workflows and AI automations are running continuously, reliability becomes less about uptime and more about making sure the system behaves predictably under real-world conditions.

The Hardest Part of Integrating with Legacy ERPs Is Not the API

Dhruvi — Mon, 01 Jun 2026 13:03:15 +0000

When people hear "ERP integration," they usually think the difficult part is the API.

Sometimes there isn't even an API.

But honestly, that's rarely the biggest problem.

The harder problem is understanding how the business actually uses the system.

Because what the ERP does and what the organization does are often two different things.

I've seen situations where:

a field means one thing in the documentation and something completely different in practice
a workflow exists because someone created a workaround five years ago
critical business rules live in spreadsheets instead of the ERP
important decisions happen outside the system entirely

Technically, the integration works.

Operationally, it's wrong.

This is where many integration projects get stuck.

The data moves successfully.

The API calls succeed.

The sync completes.

And yet users immediately tell you something is broken.

Because the integration followed the system.

Not the business process.

One thing I learned early on:

Never assume the ERP is the source of truth for how work gets done.

It's often just one piece of a much larger process.

The real workflow usually spans:

ERP systems
spreadsheets
emails
manual approvals
undocumented habits

The API is a technical challenge.

Understanding operational behavior is a people challenge.

And in my experience, the people challenge takes longer.

The best integrations I've worked on started with questions like:

Why does this process exist?

Who actually uses this field?

What happens if this step is skipped?

Those conversations usually uncover more than the technical documentation ever does.

The interesting part is that older systems are often doing exactly what they were designed to do.

The complexity comes from everything built around them over the years.

This is something we see regularly at BrainPack when connecting existing enterprise systems to modern workflows and AI capabilities. The technical connection is usually the easy part. Understanding how the organization actually operates is where most of the real integration work happens.

Something Honest About Being a Developer on This Kind of Team

Dhruvi — Thu, 28 May 2026 12:38:43 +0000

One thing I didn’t expect working on systems like this:

A lot of the job is uncertainty.

Not coding itself.

Uncertainty.

You’re constantly working across:

systems you didn’t build
workflows nobody fully documented
integrations that behave differently under production load
business logic hidden inside years of habits and manual processes Sometimes the hardest part is simply figuring out what is actually happening.

Another thing people don’t talk about enough:

You rarely get the satisfaction of “finished.”

Because the systems keep evolving.

You fix one workflow.

Then another dependency appears.

You stabilize one integration.

Then business priorities change and the flow changes again.

The system keeps moving underneath you.

There’s also a different kind of pressure when systems run continuously.

You know real operations depend on them.

If something breaks:

people stop receiving orders
workflows stop moving
teams lose visibility
data becomes unreliable

It changes how carefully you think about small decisions.

At the same time, this kind of work made me much calmer technically.

You stop panicking when things fail.

Because eventually you realize:
production systems always fail somewhere.

The goal is not perfection.

The goal is building systems that recover safely and predictably.

One thing I genuinely like about this work though:

You get very close to how businesses actually operate.

Not the clean diagrams.

The real workflows.

The weird edge cases.

The manual processes people invented just to keep things moving.

You learn quickly that software is usually less about code and more about understanding operational behavior.

Working at BrainPack exposed me to how complex enterprise environments actually are once multiple systems, teams, and AI workflows start interacting together. Most of the engineering work is not about building isolated features, it’s about making entire operational flows stable enough to trust long term.

A Technical Problem I Worked On This Week

Dhruvi — Fri, 22 May 2026 12:43:15 +0000

This week, I spent more time than expected debugging something that looked simple.

Data syncing between two systems.

One side said the record was updated.

The other side disagreed.

No errors.

No failed requests.

Everything looked normal.

Which usually means the problem is not obvious.

The issue ended up being timing.

One system updated immediately.

The other processed updates through a delayed workflow.

Most of the time it worked.

Sometimes updates arrived in a different order.

Which created small inconsistencies:

outdated values appearing temporarily
automation triggering from stale information
users seeing different states in different systems

The difficult part was that it only happened occasionally.

So reproducing it locally was almost impossible.

The fix itself was not complicated.

We changed how updates were processed.

Instead of assuming data arrives in the right order, we added validation around state changes before applying updates.

Small change.

Big difference.

One thing I keep learning working on systems that run continuously:

A lot of problems are not caused by failures.

They come from assumptions.

Assuming systems process things instantly.

Assuming updates arrive in order.

Assuming timing stays consistent.

Production environments break assumptions very quickly.

The interesting part about enterprise systems is that most technical problems are not isolated.

One small inconsistency spreads.

An automation behaves differently.

A report becomes inaccurate.

Another system trusts the wrong data.

Small problems travel.

This is something we deal with regularly at BrainPack while connecting systems that were never originally designed to operate together. AI workflows become much more reliable once the underlying data movement becomes predictable.

The Difference Between Building for Demo and Building for Production

Dhruvi — Wed, 20 May 2026 12:45:36 +0000

A lot of software looks great in demos.

Clean data.
Fast responses.
Perfect flow.

Production is where reality shows up.

A demo assumes everything behaves correctly.

Production assumes eventually something will break.

That changes how you build.

For demos:

You optimize for:

speed
presentation
showing capability

For production:

You optimize for:

failure recovery
retries
monitoring
stability
weird edge cases nobody planned for

A demo works when everything goes right.

Production works when things go wrong.

One thing I noticed early on:

Demo environments are predictable.

Production environments are messy.

You get:

duplicate events
incomplete data
slow third party systems
retries arriving late
users doing things you never expected

The code that looked perfect in testing suddenly behaves very differently.

Another difference:

Demo code usually answers:

"Can we do this?"

Production code answers:

"Can this keep working for months while real people depend on it?"

Very different problem.

One thing that changed how I build systems:

I stopped asking:

"Does this work?"

Now I ask:

"What happens when this fails?"

Because eventually it will.

The question is whether the system recovers safely.

A lot of engineering work happens after the feature already works.

Observability. Recovery. Reliability.

The things users never notice.

Until they stop existing.

This comes up constantly at BrainPack while operating systems that run continuously across enterprise environments. Layering AI on top becomes much easier once the underlying infrastructure is designed for production conditions instead of demo conditions.

A Small Fix That Helped a Live Deployment Immediately

Dhruvi — Tue, 19 May 2026 12:44:30 +0000

One of the most useful fixes I worked on recently was not complicated at all.

We added a queue between two systems that were talking to each other directly.

That was it.

Before that, everything worked fine most of the time.

Until traffic increased or one system slowed down for a few seconds.

Then things started piling up:

requests timing out
retries triggering
duplicate operations
random failures appearing across workflows

The problem was that both systems expected immediate responses from each other.

So when one slowed down, the other started failing too.

Classic cascading failure.

The fix was surprisingly small.

Instead of:
System A → direct request → System B

We changed it to:
System A → queue → System B

Now:

requests could wait safely
retries became manageable
temporary slowdowns stopped affecting the entire flow

The deployment stabilized almost immediately.

What I liked about this fix is that it changed the behavior of the system more than the complexity of the code.

No massive rewrite.
No new infrastructure layer.

Just removing the assumption that everything has to happen instantly.

A lot of production issues come from systems being too tightly coupled.

One delay becomes everybody’s problem.

Queues don’t remove failures.

They absorb pressure long enough for the rest of the system to keep operating normally.

One thing I learned working on live systems:

Performance issues are often really coordination issues.

The systems themselves are usually capable.

They just fail because everything depends on perfect timing.

This is something we run into constantly at BrainPack while integrating multiple enterprise systems and AI workflows together. A lot of stability comes from reducing tight coupling between systems so temporary failures don’t spread across the entire infrastructure.

How We Debug Issues That Only Happen Once Every Few Days

Dhruvi — Fri, 15 May 2026 12:45:23 +0000

The hardest bugs are not the ones that happen constantly.

The hardest ones are:

once every few days
under unknown conditions
with no obvious pattern Especially in systems that run continuously.

Because by the time you notice the issue, the original state is already gone.

Early on, I used to approach these bugs the wrong way.

I would immediately start reading logs and trying to reproduce the issue locally.

Most of the time, that went nowhere.

Because these problems usually depend on:

timing
retries
load
specific data states
interactions between systems

Things that almost never exist in your local environment the same way.

What changed for me was realizing:

The goal is not “find the bug immediately.”

The goal is:
make the system observable enough that the bug exposes itself next time.

So instead of guessing, we start adding visibility around the problem.

Things like:

tracking state transitions
storing retry history
recording execution timing
correlating events across systems

Not permanent debugging noise.

Just enough context to reconstruct what actually happened later.

Another thing I learned:

Rare bugs are often not random.

They usually happen when multiple small conditions align:

a delayed queue
a retry arriving late
stale data
another service slowing down

Individually, nothing breaks.

Together, something weird appears for 30 seconds and disappears again.

One mistake I made a lot before:

Trying to “fix” the issue too early.

When you don’t fully understand intermittent bugs, quick fixes usually just hide the symptom temporarily.

So now I spend more time understanding:

what sequence created the issue
what state the system was in
why recovery didn’t happen automatically

Only then do we change the flow.

The interesting part is that debugging these issues slowly changes how you design systems.

You stop building only for normal operation.

You start building for investigation too.

Because eventually, every long-running system develops behaviors you didn’t predict.

At BrainPack, a lot of debugging work involves understanding interactions between systems that only fail under very specific timing conditions. The more AI workflows and automations are layered on top, the more important observability and recoverability become.

A Tool That Saves Me Time Every Single Week

Dhruvi — Mon, 11 May 2026 12:50:54 +0000

One thing that saves me an absurd amount of time is building small internal debugging endpoints.

Not dashboards.
Not full admin panels.

Just tiny routes or tools that answer very specific questions fast.

Things like:

“show the last sync status for this customer”
“replay this failed webhook”
“show all retries for this workflow”
“compare the data between these two systems”

Early on, I used to debug everything directly from logs and databases.

It worked when systems were smaller.

But once multiple services, queues, integrations, and retries are involved, simple issues start taking way too long to trace manually.

So now, whenever I notice:
“I keep checking this manually”

I usually turn it into a small internal tool.

The interesting part is that these tools are rarely complicated.

Sometimes it’s:

one endpoint
one query
one button

But removing 20 minutes of repeated investigation every day adds up fast.

Especially in systems that run continuously.

Another thing I realized:

The best internal tools are usually built by the people operating the system directly.

Because they come from real friction.

Not assumptions about what might be useful.

A lot of engineering time is lost not on fixing problems, but on figuring out where the problem actually is.

Anything that shortens that feedback loop becomes valuable very quickly.

At BrainPack, a lot of our internal tooling comes directly from operating live enterprise systems continuously. Once AI workflows and multiple integrations are involved, reducing investigation time becomes just as important as reducing failure rates.

The Hidden Cost of “Quick Fixes” in Enterprise Systems

Dhruvi — Thu, 07 May 2026 13:27:45 +0000

Most enterprise systems don’t become messy all at once.

They become messy one quick fix at a time.

A temporary script.
A manual spreadsheet.
A copied database table.
A workflow someone added “just for now.”

Individually, none of these seem dangerous.

But after a few years, the organization is running on layers of patches nobody fully understands anymore.

The problem with quick fixes is that they solve the immediate issue while quietly increasing system complexity.

And complexity compounds.

What starts as:

one workaround
becomes:
multiple duplicate processes
inconsistent data
hidden dependencies
workflows that only one person understands

At some point, nobody trusts the system anymore.

So teams create even more manual processes to compensate.

That’s usually when things start slowing down operationally.

One thing I noticed working on these systems:

The biggest cost is rarely technical debt itself.

It’s operational uncertainty.

People stop knowing:

which system is correct
what process is actually being used
whether automations can be trusted

And once trust disappears, everything becomes slower because humans start double checking everything manually.

The tricky part is that most quick fixes are not bad decisions at the time.

The business needed something fast.
The team solved the problem.
Everyone moved on.

But systems that run continuously remember every shortcut forever.

What changed how I approach this:

I stopped asking:
“does this solve the problem?”

Now the question is:
“what does this make harder six months from now?”

Because in long running systems, future complexity is usually more expensive than the original issue.

A lot of the work we do at BrainPack starts with untangling years of accumulated workarounds across existing systems. AI only becomes useful once the underlying operations are predictable enough to trust again.

Why Logging Is Not Enough When You Operate Systems Continuously

Dhruvi — Mon, 04 May 2026 17:08:59 +0000

At some point, logs stop helping.

Not because logging is bad.
Because the system is doing too much.

When you’re running something continuously, across multiple systems, logs turn into noise fast.

You still log everything.
You just can’t rely on it to understand what’s actually happening.

The expectation

Early on, logging feels like the answer.

Something breaks → check logs → find the issue → fix it

Clean. Linear. Works in small systems.

What actually happens

In production, it looks like this:

thousands of log lines per minute
multiple services writing at the same time
retries creating duplicate entries
partial failures that don’t throw clear errors

You open logs and see everything.

Which means you see nothing.

The real problem

Logs tell you what happened.

They don’t tell you:

what state the system is in
what is currently broken
what needs attention right now

And when things run continuously, that’s what you actually need.

What we started doing instead

We still log. But we stopped treating logs as the source of truth.

1. Track state, not just events

Instead of just writing logs like:

“order created”
“order failed”

We track:

current status of the order
where it is in the flow
what’s pending

So at any moment, we can answer:

what’s stuck right now

2. Surface problems, don’t search for them

Logs require you to go looking.

In real systems, you don’t have time for that.

So we build:

alerts when something is off
dashboards that show broken flows
queues that show backlog

The system tells you where to look.

3. Group by flow, not by line

Logs are isolated lines.

But real issues happen across a sequence.

So we group things by:

request
entity
workflow

Instead of reading 100 lines, you follow one story.

That’s where things start making sense again.

4. Accept that some issues won’t be obvious

Some problems don’t throw errors.

They just… stop moving.

A process gets stuck.
A sync silently fails.

Logs might show nothing critical.

So you need signals like:

time thresholds
missing updates
“this should have finished by now”

What changed for me

I used to think:

if it’s logged, we can debug it

Now I think:

if we need logs to notice something is broken, we’re already late

Logs are for digging deeper.

Not for discovering the problem.

In systems that run all the time, you don’t watch everything manually.

The system needs to show you where it’s struggling.

Otherwise, you’re just scrolling and hoping you notice the right line.

This is something we run into a lot at BrainPack, where multiple systems are always moving and interacting. AI workflows depend on knowing the current state of everything, not just what happened, so observability has to go beyond logs.

How We Design Systems That Keep Working Even When One Part Fails

Dhruvi — Thu, 30 Apr 2026 13:14:46 +0000

In real systems, something is always failing.

An API times out.
A database slows down.
A third-party service returns garbage.

If your system depends on everything working perfectly, it won’t last long in production.

So the goal is not preventing failure.

It’s designing so failure doesn’t break everything.

The wrong assumption

A lot of systems are built like this:

Step 1 → Step 2 → Step 3 → Done

If Step 2 fails, the whole flow stops.

In controlled environments, this works.

In production, it creates fragile systems that break on the first issue.

What we do instead

We design flows that can survive failure and continue.

Not perfectly. But safely.

1. Break the dependency chain

Instead of one long synchronous flow, we split things into independent steps.

Each step:

does one thing
stores its state
can be retried

So if something fails, you don’t lose everything.

You just retry that part.

## 2. Accept partial success

This one is uncomfortable at first.

Sometimes:

part of the system succeeds
another part fails

Instead of rolling everything back, we:

keep what succeeded
fix what failed

Because in distributed systems, “all or nothing” is rarely realistic.

3. Make retries safe

Failures lead to retries.

Retries lead to duplication if you’re not careful.

So every step needs to be safe to run again:

no duplicate records
no repeated side effects
no broken state

If retries are safe, failure becomes manageable.

4. Isolate external dependencies

Anything outside your control will fail eventually.

So we isolate them:

queues between systems
timeouts and fallbacks
delayed execution when needed The goal is simple

If one system goes down, everything else should keep moving.

5. Design for recovery, not perfection

Instead of asking:

how do we make this never fail

We ask:

how does this recover when it fails

That changes everything.

You stop chasing edge cases and start building systems that handle them naturally.

What changed for me

I stopped treating failure as an exception.

Now it’s part of the normal flow.

Every system I build assumes:

something will fail
it will fail at the wrong time
and it will fail more than once

So the system needs to absorb that without collapsing.

In systems that run continuously, reliability doesn’t come from everything working.

It comes from everything being able to keep going when something doesn’t.

This is something we deal with constantly at BrainPack, designing systems that keep operating even when parts of the infrastructure fail. AI workflows only work if the underlying systems can recover and continue without breaking the overall flow.