DEV Community: Alex N.

Extending a Live Institutional Trading Platform Without Breaking It

Alex N. — Wed, 10 Jun 2026 02:27:35 +0000

The most dangerous move on a regulated fintech system? Assuming you understand it before you actually do.

Rule number 1 in development: never assume anything.

Here's what it looked like when we extended a live institutional trading platform - AFSL-licensed, handling perpetuals, spot, options, and FX - without a single regression, in production, with people watching very closely.

We joined a live system that was already in production
This wasn't a startup with a blank slate. The platform was already live - real users, real trades, real regulatory obligations. The core system ran on C#/.NET and PostgreSQL, with a separate compliance portal handling KYC/AML and onboarding.

Our client needed three things: a multi-channel notification system, extended API capabilities, and an independent security assessment before scaling further.

What they didn't need was for us to arrive with opinions about how we'd have built it differently. Our mandate was to extend the system, not reimagine it.

We started by reading the system, not writing code
Every new module we shipped had to be architecturally indistinguishable from what already existed. Not just functional - indistinguishable. We matched naming conventions, followed established patterns, and held to a strict propose → approve → implement workflow before anything hit production.

So before anyone opened a ticket, we read the system. We used AI tooling - including Claude - to map architectural patterns, identify conventions, and build a mental model of how the system was designed to evolve. We documented every assumption. We validated every proposal before implementation. We shipped every PR with design rationale, not just a diff.

💡 This is not how most teams behave under delivery pressure. It is, however, the only approach that works when you're extending a production system you didn't build.

03 things that kept production stable
Test-first as structure. We enforced 100% unit test coverage, which forced us to understand every execution path before we considered a feature done. We used AI tooling to generate cases and surface uncovered paths. The byproduct wasn't just coverage - it was a genuine understanding of the system's edge cases.

Documentation in every PR. Not what we changed - why. The design decision, the alternatives, the tradeoffs. In a system where teams grow and engineers rotate, this is what stops the next person from repeating our mistakes.

AI for comprehension, not generation. We used it to read the codebase at scale - pattern recognition, consistency checking, spotting where a change might interact with existing behavior in non-obvious ways. We got better proposals and fewer surprises as a result.

💡 Our goal wasn't to move fast - it was to move correctly. Turns out that's also faster, just not immediately.

The compliance portal had 31 security findings
The compliance portal wasn't broken. It handled KYC/AML, onboarding, and document management without issue. From the outside, there was nothing to flag.

But we knew that functioning and secure are not the same thing. Scaling an institutional business on an unassessed compliance portal isn't just a technical risk - it's a strategic one. So we ran an independent assessment before our client expanded their institutional customer base further.

We found 31 findings across multiple severity levels. Several were critical: personal data protection, access control, and financial data handling - the exact areas where failure doesn't generate a support ticket. It triggers a regulatory event.

We delivered a structured remediation roadmap so our client could address these before scaling. That was the point - not to flag problems, but to give them a clear path forward.

💡 "Working fine" is not a security posture. It's just what failure looks like before it happens.

What made the engagement work
Three things explain most of what went right.

Understand before you improve. The hours we spent building a real mental model - of how the system actually worked, not how we'd design it today - were the hours that prevented expensive mistakes later. We protected that learning phase even when timelines were tight.

Different stacks, different risk profiles. A core trading platform and a compliance portal are not the same kind of system. We didn't apply a single risk standard universally. A medium-severity finding in one context can be critical in another depending on what data it touches.

Critical feedback is data. Fintech reviews are demanding by design. We responded with evidence and consistent judgment - and stopped being a vendor. We became the partner they trusted with the sensitive stuff.
In regulated fintech, trust is the product. The discipline is just how you earn it.

Inherited a live regulated system?
👉 What was the moment you realized "move fast" wasn't going to work here?
Drop it in the comments.

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!