DEV Community: Alex N.

No Docs. Live Banking System. “Where do I start”?

Alex N. — Thu, 16 Apr 2026 07:27:41 +0000

If you've worked across enough projects, it's not a matter of if you'll inherit an undocumented codebase — it's when.

When that happens, you’ll soon see that there’s nothing that tests your nerve quite like getting repo access on day one - no README, no architecture diagram, no handover doc and realizing the system you're now responsible for is processing real payments across four countries.

My first instinct? Start poking around to "see what happens."
J/k, I didn't (seriously, don’t do that).

This is what I'd tell any developer dropped into the same situation — a real lesson from someone who's navigated a live, undocumented banking system as part of an embedded team.

Day One: The Zero-Documentation Problem
😫 If you've ever joined a banking project mid-flight, you already know: the docs don't exist because the people who built the system were too busy keeping it alive.

When you land in an undocumented codebase, two moves feel obvious:

Ask the in-house team to walk you through everything
Poke around and "see what happens"

Both will hurt you.

The in-house team is already running hot. Long walkthroughs burn their goodwill fast and you'll need that goodwill later for questions that actually matter.

And "see what happens" is perfectly fine on a POC/personal project. Not on a live payment system moving real money across countries.

The goal before you touch anything: build a mental model. Not fix things. Not ship things. Just understand.

How to Navigate a Live Codebase Without Breaking Anything
1. Read first. Change nothing
I see that many novice developers will be more likely to jump into a new codebase looking for something to fix. Quick win, show value, right?
Wrong.

The right mindset should be: "Don't rush to deliver. Rush to understand. The first few weeks are an investment; cut corners here, and you'll pay for it in production."

We dug into the PHP codebase methodically, tracing execution paths, mapping transaction flows end to end. No shortcuts. No assumptions.

It felt slow but not at all in reality, where you shipped firmly, and you knew you’re doing the right call.

💡 In a live financial system, your first job isn't to ship, it's to not break anything. Earn the right to make changes by understanding what's already there.

2. Hunt the business logic, not just the code

There's a difference between reading code and understanding a system. That gap is business logic, and in fintech, that gap can be enormous.

Our PM pushed us to keep a running doc of every "why does this exist?" question as we read. Some answers came from the code itself. Some from git history. Some from short conversations with the in-house team.

That doc became our first draft of the documentation that never existed.

💡 The goal isn't just to understand what the code does, it's to understand why the business needs it to do that. Those are two very different questions.

3. Ask small, specific questions
When we did go to the in-house team, we came prepared.
Short questions. Specific scenarios. "We think the flow works like X - is that right?" Not "can you explain the whole system to us."

We had a rule: the in-house team is our ally, not your search engine. Come with hypotheses. Respect their time. You'll get better answers and burn less goodwill.

💡 One sharp, well-framed question gets you further than ten open-ended ones. Do the reading first, then ask.

4. Document as you go, not at the end

Your confusion today is your next teammate's onboarding nightmare tomorrow.

Write it down while it's fresh - the weird edge cases, the non-obvious dependencies, the "oh, that's why it does that" moments.

We treated documentation as a team deliverable from day one, not an afterthought. When 6 more engineers joined our team months later, that living doc cut their ramp-up time significantly.

💡 Documentation written mid-confusion is more useful than documentation written after you understand everything. The questions you're asking right now are exactly what the next person will need answered.

What I Learnt When the Codebase Is Also a Live Payment System

Everything above applies to any undocumented codebase. But if you're working in fintech or banking — if the system you've just inherited is processing real transactions, moving real money, operating under regulatory scrutiny — the methodology isn't just useful. It's non-negotiable.

Every unvalidated assumption is a risk. In a payment system, that's not abstract. It's real money, real users, real consequences.

"Observe before intervene" isn't just good advice, it's the professional standard in live financial infrastructure. Treat it like a rule, not a suggestion.

Your first contribution should be small, validated, and reversible. Prove you understand the system before you change it. A clean, careful first PR builds more trust than shipping fast and breaking something.

The higher the stakes, the more this process matters. Not less.
👉 Here's the case study behind this story: Rebuilding a Live Payment Core - Across 4 Markets, With Zero Documentation
👉 Have you ever been in the same situation? Let’s share thoughts in the comments.

5 Things I Learned Working With A Lead BA On A Cross-Border EHR System

Alex N. — Mon, 23 Mar 2026 08:55:21 +0000

As a dev, there is nothing I hate more than spreadsheets of "enterprise digital transformation" or 40-page PDFs of "perfect world" scenarios that sound smart in a meeting but totally lack actual logic.

We’ve all seen those requirements: "System should magically sync legacy data with the new cloud DB." That usually results in hours of Slack argument threads. ALL. DAY.

😫 Too many times, the BA writes the "dream," and the technical nightmares are left for the devs to figure out.

That was my baseline until I got pulled into a high-stakes HealthTech build with Mai Anh Le, our Lead BA at Sun*. After watching her navigate a cross-border EHR modernization project, I’ve had to completely rethink what a BA actually does.

👇 Here is what I learned from a global scaling EHR integration project with a BA who actually knew what "business logic" she needed to analyze and what requirements should be delivered to the tech team:

1. Map the physical user movement before designing the schema

I used to grab a ticket and start thinking about database tables immediately. But this time, I realized that in HealthTech, digitalization is a failure if it adds 30 seconds of friction to a doctor’s day.

Instead of jumping into system design, our BA made us spend the first two weeks mapping how work actually happens in a clinic. We traced every step—from a patient touching an IoT device to how that data hits a nurse's dashboard.

💡 If you don't understand the "day-in-the-life" workflow, you’ll build "clean code" for a theoretical flow that won't survive a "busy Tuesday" in a real clinic. Now, I don't touch a feature until I know why it exists in the physical world.

2.Clinical hardware defines the logic of the tech you develop

It’s a rookie mistake to assume you can build one "universal" ingestion engine. Every clinical device is its own isolated ecosystem with its own assumptions about data hand-offs.

With our BA's guidance, I learned that a neurology treatment plan isn't just "different data", it’s a different architectural requirement based on the specific hardware being used.

💡 Treating medical devices as generic inputs is the fastest way to accrue technical debt you can't pay back. We used HAPI FHIR, Node HL7, and RabbitMQ not just to move data, but to handle the unique "semantics" of each piece of clinical hardware.

3. Compliance is an architectural constraint, not a documentation task
"GDPR or HIPAA was just a checklist for the legal team ?". I was wrong. When scaling a healthcare service from one territory to another, compliance changes the very way you handle data provenance and storage.

Our BA approached compliance as a core product requirement. We embedded granular Role-Based Access Control (RBAC), encryption, and full audit trails directly into the system architecture from day one.

If you try to think compliance later, thank again. You'll for sure end up refactoring the entire core. To avoid this, she relied on a rigorous checklist I now use for every sprint:

Who actually uses this system?
Which stakeholders are involved at each step?
Where does the data hand off?
What does the receiving system actually expect?

4. Front-load the Analysis to Prevent 11th-hour Structural Rework
We had 60 days to launch a global EHR system across Europe and Asia.

We spent the first two weeks "quietly" mapping every handoff and system boundary. I thought we were losing time. I was wrong (for the second time). Because she locked the logic down early, our engineering team executed the build with nearly zero structural rework.

💡 Speed doesn't come from typing faster; it comes from not having to build the same feature twice. We launched on time because our foundation was solid, not because we rushed the implementation.

5. Use AI for fast research, but use human experience for risk mitigation
We used AI daily to summarize FHIR R4 guides, which boosted our research efficiency by about 70%. But I noticed a pattern: while AI gives you the answers, a Lead BA knows if you’re asking the right questions.

💡 AI is a powerful engine for information retrieval, but it is terrible at judging clinical risk. In high-stakes environments, you need a human who has seen how systems fail in the real world to decide which AI-generated suggestions are safe to implement.

Working with a Lead BA who understands systems thinking changed my perspective. A great BA isn't a "requirement gatherer"—they are a Strategic Risk Mitigator. When the BA handles the logic, we Devs can focus on building high-performance systems that actually change lives.

👉 Have you ever had a project saved (or ruined) by a BA’s logic? Let’s swap stories in the comments.

👉 Check out more insights in healthcare technology development here!