DEV Community: Aakash

From on-prem to the cloud - Lessons Learned

Aakash — Sun, 03 May 2026 08:36:11 +0000

A recent conversation with Raymond Oyondi on Peerlist made me rack my memories a bit and reflect on how much software and infrastructure have changed over the years.

I joined the industry back when cloud still felt more like a concept than a default. A lot of systems were still being built and maintained in environments where the infrastructure was very much in your hands. You knew the machines, the network, the limits, the weak points. If something needed scaling, it was not a button click and a dashboard graph. It meant spinning up another server, configuring it, wiring it into the network and load balancer, deploying the application, syncing state, setting up monitoring, and making sure the whole thing did not fall apart under pressure. We had automation in places, of course, but nowhere near the kind of convenience people now take for granted.

A lot has changed since then. But the funny thing is, the biggest lesson for me is that the old principles never really went away.

Cloud changed the speed. It changed the abstractions. It changed how easily we can provision, scale and recover. But it did not change the laws underneath. Capacity still matters. Latency still matters. State still causes pain. Network boundaries still introduce failure. Bad assumptions still come back to collect interest.

That is probably the biggest thing I learned moving from on-prem and bare-metal thinking into cloud-native systems: the tooling changed more than the fundamentals did.

Earlier, a lot of software lived as one big application. One service, one deployment unit, one giant block with hard coupling inside it. It was not always pretty, but it was straightforward in one sense: most of the complexity lived inside the application itself. Since the infrastructure was under our control, nobody really panicked about it. You managed the box, tuned the app, scaled when needed, and kept things moving.

Then cloud became normal, and with it came speed, flexibility, and a different cost model. Suddenly, scaling was easier. You no longer had to treat infrastructure changes like a mini project every single time. But that convenience also exposed something important: a lot of monoliths were expensive in ways people had not fully noticed before.

You would see an application chewing through resources and the default response would be to scale the whole thing. More compute, more memory, more replicas, more money. But when you looked closer, often only certain parts of the application were actually responsible for that load. Maybe one workflow was CPU-heavy. Maybe one module was doing aggressive I/O. Maybe one part had bursty traffic while the rest of the system just sat there minding its own business.

That is where the architectural shift really starts to make sense.

Instead of treating the software like one sealed black box, you begin to see it as a collection of components with different scaling patterns and different operational needs. So you start isolating them. You break out the hot paths. You separate the parts that need to scale from the parts that do not. Pretty soon, what used to be a monolith starts becoming a patchwork of smaller services talking to each other.

And yes, that can absolutely be the right move.

But I also think this is where a lot of people get seduced by architecture diagrams and forget the bill that comes later.

Microservices are not free. They reduce one kind of pain and introduce another. You gain independent scaling, but you also gain more network hops, more deployment surfaces, more observability needs, more operational coordination, more failure modes, and more opportunities for state to become inconsistent. The complexity does not disappear. It just moves.

Earlier, if two parts of the system needed to coordinate, that problem often lived inside one process boundary. Now it may live across services, shared storage, queues, caches, retries, and eventual consistency rules. You may need supporting software to make the architecture work. You may need shared storage. You may need to handle read-write races and stale data. You may need to think much harder about idempotency, ordering, duplicate events, and what “correct” even means in a distributed system.

So for me, the lesson was never “microservices good, monolith bad.” That is too simplistic and honestly a bit lazy.

The real lesson was this: design around the behavior of the system, not around fashionable architecture labels.

If one deployable unit works, keep it one deployable unit. If certain modules clearly have different scaling needs, isolate them. If you are introducing distributed complexity, make sure the benefits are worth the operational cost. Use the minimum supporting software necessary. Every extra moving part is one more thing to monitor, patch, debug, secure and explain at 2 AM.

Another lesson that became much more obvious in the cloud-native world is that deployment topology matters a lot more than many developers initially think. Two services talking to each other on a diagram is easy. The actual topology, where they run, how they communicate, what latency sits between them, how failover behaves, where state lives, and what happens during partial failure, is where reality begins.

I have also come to appreciate observability discipline much more over time. In distributed systems, tracing tools are great and OpenTelemetry has helped a lot, but tooling alone does not save you. If your logs are inconsistent, your labels are exploding in cardinality, your trace attributes are a mess, and every team names the same thing differently, you are not observing a system. You are generating noise. Good observability needs discipline: standard log formats, sensible naming conventions, rules for metrics and labels, and a sampling strategy that matches the criticality of the application. Otherwise, you either drown in telemetry or pay too much to keep it.

So when I think about high availability at scale, my biggest lesson learned is actually a simple one.

Break systems into modules where it genuinely helps. Keep supporting software to a minimum. Be aware of deployment topology. Respect state. And never assume cloud removed the need for sound systems thinking. It did not. It just made it easier to build distributed systems before earning the scars required to run them well.

Cloud is powerful. But it is still someone else’s computer. And the old bare-metal lessons still hold stronger than people think.

Quick Hack: Save up to 99% tokens in Coding Agents

Aakash — Fri, 01 May 2026 02:19:38 +0000

Anyone using coding agents like Codex must be aware of the pains of stricter token limits. I am on the Plus plan and the 5-hour limits are so short, they are really annoying. Came across a package called distill - https://github.com/samuelfaj/distill - which claims to reduce token usage by 99%. Behind the scenes, it works by by compressing command output using a LLM (local or hosted) before it reaches the model. Well, I started using it and it is helping in extending my sessions. Sharing in case it helps others stretch their limits a bit further.

Known Issues -

The latest build supports Windows but hasn't been published in npm yet. If you stumble upon it, just like me, use the commands in this comment to set it up (or just copy them from the end of this post).
It silently fails for newer, reasoning models, like the GPT-5 family. I have submitted this issue to add support for the newer models and working on a fix (hope the maintainer is open to contribution!). Meanwhile, use it with the non-reasoning models like gpt-4o, gpt-4.1 or gpt-5-chat-latest

Windows Install Commands

Install bun - npm install -g bun
Clone and install - git clone https://github.com/samuelfaj/distill.git; cd distill; npm install
Build the binary - npm run build:bins
Add to path -

   New-Item -ItemType Directory -Force packages\distill-win32-x64\bin | Out-Null
   Copy-Item .dist\bun-windows-x64\distill.exe packages\distill-win32-x64\bin\distill.exe -Force

Once that's done, try verifying -

PS D:\custom_pnpm\distill> distill --version
1.4.1

Why Most Bank Statement Converters Fail

Aakash — Sun, 29 Mar 2026 12:47:44 +0000

Aakash

Mar 29

Why PDF Bank Statement Conversion Is Harder Than It Looks

#ai #fintech #saas #productivity

Comments

6 min read

Why Just PDF-to-Excel Is Not Enough For Bank Statements

Aakash — Sun, 29 Mar 2026 12:47:05 +0000

Aakash

Mar 29

Why PDF Bank Statement Conversion Is Harder Than It Looks

#ai #fintech #saas #productivity

Comments

6 min read

Why PDF Bank Statement Conversion Is Harder Than It Looks

Aakash — Sun, 29 Mar 2026 12:45:43 +0000

TL;DR

A bank statement PDF to Excel converter sounds like a solved problem until you actually start looking at real statements. The easy part is getting some rows out. The hard part is getting output that somebody can trust enough to use without doing half the work manually again.

That was the big realization for me.

What looked like a simple OCR or extraction problem turned out to be a much uglier workflow problem involving layout variance, scanned documents, broken tables, inconsistent debit and credit conventions, balance mismatches and a very unforgiving downstream use-case. In accounting and bookkeeping workflows, “almost correct” is often just a slower form of manual work.

That is the problem space I ended up getting into with a friend of mine, and it eventually became the basis for Smart Bank Statement.

The naive version of the problem

On paper, this problem sounds embarrassingly simple.

Take a PDF bank statement. Extract the rows. Put them into Excel or CSV. Done.

That is how most people think about it at first, and honestly, that is also how a lot of tools position it. They talk about conversion as if the job ends the moment rows appear in a spreadsheet.

But that framing hides the real problem.

Because when somebody says they want to convert a bank statement PDF into Excel, they usually do not mean “give me some table-like output.” They mean “give me data that is clean enough to reconcile, import, audit or work with downstream without me babysitting every row.”

That is a much higher bar.

Once you use that bar instead of the softer “did we extract something?” bar, the problem changes shape immediately.

Where things start breaking

A lot of document workflows look good right until you leave clean demo inputs and meet real files.

Bank statements are especially annoying because the documents vary in all the ways that matter. Some are digital PDFs with selectable text. Some are scanned. Some have low quality images. Some use multi-column layouts. Some place debit and credit in separate columns. Some collapse them into one amount column and expect the sign convention to imply direction. Some carry balances row by row. Some do not. Some have strange description wrapping or continuation rows. Some have pages where the statement header, footer or summary table looks suspiciously like transactional content.

And then there are the really fun ones: documents with multiple accounts in one file, broken table boundaries, passbook-style formats or statements where the extraction is not catastrophically wrong, just subtly wrong enough to waste your afternoon.

That last category is the one I dislike most.

If the extraction completely fails, at least the failure is obvious. If it succeeds just enough to look plausible while still shifting a row, dropping a value or distorting a balance trail, the user has to detect it manually. In finance workflows, that is where trust gets destroyed.

Why OCR accuracy is the wrong metric

One thing I became more skeptical of very quickly is marketing around raw OCR accuracy.

The reason is simple: accuracy by itself is too vague to mean much in this context.

A tool can claim very high extraction accuracy and still fail the actual workflow. It can extract text well and still produce inconsistent structure. It can identify numbers correctly and still associate them with the wrong row. It can read a page and still mis-handle the running balance. It can parse a date and still break when a narrative spills across lines.

So the real question is not just, “How accurately did you read the document?”

It is, “Can the output be trusted enough that the user saves time instead of spending that time validating the tool?”

That is a very different metric.

In bookkeeping or accounting, 99% correctness is not automatically good if the missing 1% takes disproportionate effort to find. One bad transaction can force somebody to retrace the whole sheet. A balance mismatch means somebody has to stop and investigate. A few line items shifted out of place can make a reconciliation job unreliable.

So for me, this stopped being an OCR problem pretty fast. It became a trust, validation and downstream-structure problem.

The market realization

This part also changed how I thought about the product side of it.

When I first got into this space, the broader finance angle looked tempting. Dashboards, summaries, analysis, personal finance views, maybe even a bigger “financial intelligence” layer. That all sounds interesting, and it demos well.

But the pain there felt softer.

The harder, more immediate pain was earlier in the pipeline: getting messy statements into a usable format in the first place. Before dashboards, before analytics, before any fancy insight layer, there is an ugly preprocessing problem. And if that problem is not solved well, everything after it gets contaminated.

That was where things started becoming more compelling.

My friend Rupam had already been exploring the space when I got involved. Once I joined, a lot of our conversations became less about “what broad finance thing can we build?” and more about “where is the sharper workflow pain, and what are people already wasting time on?”

That question led us toward bank statements and document conversion much more strongly than toward the analyzer-style direction.

What building around this taught me

The first lesson was that “PDF to Excel” is one of those phrases that hides an enormous amount of unpleasant detail behind a very normal-sounding sentence.

The second lesson was that narrowing the product made it stronger.

There is a strong temptation, especially early on, to make a product broader because broader sounds more ambitious. In reality, broader often means blurrier. The more we looked at the workflow, the more it made sense to stay focused: take bank statement PDFs, extract the data, normalize it properly and make the result actually usable.

The third lesson was that extraction is only one layer. Validation matters just as much. In some cases, more. If you do not have ways to detect suspicious output, verify balance consistency or surface probable mistakes, you are not really solving the full problem. You are just producing output that still needs human suspicion attached to it.

And once human suspicion becomes mandatory, part of the product value disappears.

What we ended up building

That is the line of thinking that eventually became Smart Bank Statement.

Rupam had the initial seed of the idea. I joined once things were already moving, and together we pushed it through the more difficult stage: looking harder at the market, rejecting the softer and more crowded direction, narrowing the scope and getting an MVP built around a workflow that felt painful enough to matter.

I do not find that story as glamorous as the polished startup version where the product vision arrives fully formed from day one. But it is closer to how real products actually happen.

Aakash — Mon, 16 Mar 2026 18:39:25 +0000

Aakash

Mar 16

The day my MCP adapter stopped being just plumbing

#showdev #ai #mcp #security

Comments

6 min read