DEV Community: Momin Ali

University ERP: 13-Module Institutional Management Platform

Momin Ali — Thu, 16 Apr 2026 09:55:09 +0000

WHAT MOST PEOPLE DON'T REALIZE ABOUT BANKING SOFTWARE

When people think about software for banks, they usually think about the customer-facing side: mobile apps, internet banking, transaction interfaces.

That's the visible layer.

But underneath it, banks run on a completely different category of software: internal operations systems that manage everything from physical assets and procurement to tax compliance, vendor contracts, and fleet logistics. These systems are invisible to customers but critical to everything the bank does operationally.

For 15 months, from November 2022 to February 2024, I was part of the engineering team that built one of these systems for IFIC Bank, one of Bangladesh's largest private commercial banks.

What we delivered was a 20-module Financial ERP covering the bank's entire internal operations lifecycle. This is the story of what that actually involved: the scope, the complexity, the technical decisions, and what building software at banking-grade standards taught me.

THE SCOPE: 20 MODULES, ONE SYSTEM

The first thing that strikes anyone looking at this project is the sheer breadth of what needed to be built.

Twenty modules. Each one a complete functional system in its own right. Each one deeply interconnected with the others. All of them operating inside the compliance and audit requirements of a regulated financial institution.

Here's what the full scope looked like:

Asset Lifecycle Management

Fixed Asset Management handled the complete lifecycle of every physical asset the bank owned, including acquisition, depreciation, location tracking, maintenance scheduling, and valuation reporting. Disposal Management covered the formal process of retiring assets, with approval workflows, write-off accounting, and audit documentation. Together these two modules gave the bank a single source of truth for its entire asset portfolio.

Financial Operations

General Ledger was the financial backbone of the entire system. Every transaction across every module flowed into the GL, ensuring that procurement orders, asset write-offs, rental payments, and vendor invoices all reconciled automatically into accurate financial reporting. Budget Control sat on top of this, giving department heads real-time visibility into spending against allocated budgets.

Procurement & Inventory

Procurement managed the full vendor engagement cycle: requisitions, approvals, purchase orders, goods receipt, and payment processing. Inventory tracked stock levels across the bank's locations in real time, triggering procurement workflows automatically when thresholds were crossed.

Compliance & Tax

VAT & Tax Management automated tax calculation across all procurement and payment transactions, ensuring compliance with Bangladesh National Board of Revenue requirements. Archive Management maintained a complete, searchable record of all documents and transactions for regulatory audit purposes.

Operations & Logistics

Cash in Transit managed the movement of physical cash between bank branches, including tracking, authorization, and reconciliation. Transport Pool handled the bank's fleet of vehicles: assignment, maintenance scheduling, fuel tracking, and cost allocation. Rental Management covered the bank's leased properties and equipment.

Workforce & Vendor Management

Outsourced Manpower tracked third-party vendor workforce deployed across the bank's operations. Resource Tracker managed internal resource allocation across departments and projects.

Communication & Delegation

Memo digitized the bank's internal formal communication workflows. Delegation Management handled authority handoff, ensuring that when a senior official was unavailable, their approvals and responsibilities transferred correctly to designated alternates.

Core Banking Integration

CBS Integration connected the entire ERP to IFIC Bank's Core Banking System so that financial transactions in the ERP reflected accurately in the bank's core financial records in real time.

Twenty modules. Built as one coherent system.

THE TECHNICAL DECISIONS THAT MATTERED MOST

Working on a system at this scale forces you to make architectural decisions that have consequences for years. Here are the ones I think about most when I look back at this project.

The General Ledger Integration Problem

The hardest architectural challenge in any multi-module financial system is keeping the GL accurate across all transaction types. When a procurement order is raised, approved, goods are received, and payment is processed, each of those events has a different accounting implication. When an asset is disposed of, the write-off needs to flow correctly into the balance sheet. When a rental payment is made, it needs to be allocated to the right cost center.

Getting this right required designing a transaction event system where every module published standardized financial events, and the GL consumed them through a consistent interface. This meant the GL didn't need to understand the business logic of procurement or asset management. It just needed to receive well-formed financial events and record them correctly.

This separation of concerns sounds obvious in principle. Making it work across twenty modules with different data models and business rules required significant upfront design discipline.

Banking-Grade Audit Trails

Banks operate under regulatory requirements that demand complete, tamper-evident records of every system action. Every approval. Every modification. Every status change. With a timestamp, a user identifier, and a before/after state.

This wasn't an afterthought. We designed the audit trail infrastructure before we built the first module. Every write operation in the system passed through a centralized audit layer that recorded the change without the individual module needing to implement it explicitly. This kept the audit logic consistent and ensured nothing slipped through.

The CBS Integration Architecture

Connecting the ERP to the Core Banking System was one of the most technically sensitive parts of the project. CBS systems in banking are mission-critical infrastructure, and any integration that affects their data integrity or performance is treated with extreme caution.

We designed the integration as a one-directional financial sync. The ERP pushed validated, reconciled financial summaries to the CBS at defined intervals, rather than writing directly to CBS tables in real time. This protected CBS stability while ensuring the ERP's financial data stayed aligned with the bank's core records.

Role-Based Access Control at Scale

Twenty modules. A large organization. Multiple departments. Strict need-to-know data access requirements. The permission system needed to be granular enough that a procurement officer could see their module's data without seeing HR records, while a finance manager could see GL entries from all modules without accessing operational details.

We built a hierarchical RBAC system where permissions were defined at the module level, the feature level, and the data level independently, giving system administrators the flexibility to configure access precisely without needing developer intervention for every new role.

WHAT BANKING-GRADE DEVELOPMENT ACTUALLY MEANS

Working in a banking environment changed how I think about software quality in ways that have stayed with me on every project since.

In most software environments, "it works" is an acceptable standard for shipping. In banking, "it works" is the starting point for a much longer conversation.

Does it work correctly under every edge case? Does it fail gracefully when an external system is unavailable? Does it produce audit-ready records of every transaction? Does it handle concurrent access without data inconsistency? Does it enforce authorization at every level, not just the API surface?

These questions are standard in banking. They should be standard everywhere.

The discipline of designing for correctness first, not just functionality, is something I now apply to every system I build, regardless of the industry. A university payroll system that pays people incorrectly has the same severity of consequence as a banking system that misrecords a transaction. The stakes are just differently visible.

WHAT I TAKE FROM THIS PROJECT

Fifteen months on a 20-module banking ERP taught me things about system design that I couldn't have learned any other way.

I learned that large systems don't fail because of bad code. They fail because of bad boundaries: modules that know too much about each other, data models that can't accommodate business rule changes, integration points that couple tightly to implementation details that change.

I learned that in high-stakes environments, the most valuable engineering skill isn't writing fast code. It's asking the right questions before writing any code. Understanding the compliance requirement before designing the data model. Understanding the approval workflow before building the API. Understanding the reporting need before choosing the schema.

And I learned that the best way to build something at this scale is with a team that takes collective ownership, where every engineer understands not just their module but how their module fits into the whole.

That systems thinking (designing for correctness, designing for boundaries, designing for the whole) is what I bring to every project I take on now.

CLOSING

If you're building internal operations software for a financial institution, an enterprise, or a complex organization, and you need engineers who understand what banking-grade delivery actually requires, I'm available for consulting and development engagements.

📩 Send me a direct message or connect directly. I'm happy to talk through what you're building.

Building an In-House Garments ERP: Lessons from the Factory Floor

Momin Ali — Thu, 09 Apr 2026 05:58:32 +0000

The Gap Between Factory Operations and Software

Bangladesh's garment industry is one of the most operationally intense environments in the world.

Raw materials arrive from many suppliers. Production runs across knitting, dyeing, finishing, each with its own workflow, quality checkpoints, and material consumption. A large workforce works in shifts. Inventory moves fast and must stay accurate at every stage.

Most mid-sized manufacturers still run this complexity the way they always have: spreadsheets, physical registers, WhatsApp between supervisors, and institutional memory held by a few experienced people.

It works, until it doesn't.

A shipment slips because nobody saw inventory running low until it was too late. A payroll dispute takes days to untangle because attendance lives in one place and salary math in another. A batch vanishes between knitting and dyeing because the system of record is a notebook.

In 2021, Texeurop, a mid-sized textile manufacturer in Gazipur, decided to replace those disconnected habits with one integrated ERP built for how the factory actually ran.

I was on the engineering team that built it.

Why factory software is different

Before we wrote serious code, we spent time on the factory floor. That wasn't optional. It was the only way to learn what the software had to do.

Factory operations have a logic that doesn't drop cleanly into a requirements doc. The people who know it best are supervisors and floor staff who rarely think in data models or API endpoints. They think in batches, rolls, shifts, and physical movement.

Turning that reality into architecture is the core challenge of factory ERP. Get it right and the system melts into the workflow. People use it because it matches how they already think. Get it wrong and the system fights the workflow. People route around it, data rots, and the ERP is shelfware in six months.

Three things became obvious from that time on the floor.

1. Inventory is not "simple stock"

Yarn, fabric, dye, chemicals: they carry attributes that matter operationally: batch numbers, supplier codes, quality grades, physical bin or zone. Quantity alone is only half the picture; without those attributes, the system stays partially useful at best.

2. Production tracking must follow the material, not only the order

When a yarn batch moves from knitting to dyeing, the system must answer: where is this batch now, and what has been done to it? Generic inventory products aren't built for that handoff.

3. Factory HRMS ≠ office HRMS

Shift attendance, overtime, worker categories, pay structures, leave: in a plant, absenteeism directly hits output. That doesn't map neatly onto HR tools designed for desk workers.

Those three insights shaped the whole architecture.

Three modules and what they actually required

Inventory management

The inventory module had to cover the full material lifecycle: supplier receipt → production consumption → finished-goods dispatch.

Goods-in meant more than quantity: batch identity, supplier context, inspection status, warehouse location. When a knitting supervisor needed yarn, they could see what was available, where it sat, and what had cleared QA.

Movements were tracked warehouse → floor, knitting → dyeing, dyeing → finished goods, so leadership could see material flow without chasing supervisors for manual reports.

Minimum stock thresholds and alerts gave procurement lead time before a line went idle. In a plant, a late raw-material shipment is not a spreadsheet problem; it's downtime.

Knitting module

Knitting tied production runs to specific raw-material batches. If quality blew up later in dyeing or finishing, you could trace back to the exact yarn batch and run.

Work orders carried machines, targets, specs and compared actual output vs plan so supervisors saw progress without a parallel status ritual.

Inventory integration went both ways: consuming yarn updated stock automatically; transferring greige to dyeing recorded the handoff and batch location/status in one motion.

Dyeing module

Dyeing is high variance: the same greige can yield different outcomes from recipe, temperature, time, operator practice. To keep quality consistent, you need process parameters tied to outcomes.

We recorded dye batches, chemicals, time, inspection results alongside production so quality could link defect patterns to specific runs and parameters, not guesswork.

Knitting → dyeing stayed continuous: no re-keying, lower risk of losing a batch in the departmental gap.

The hardest problems

Mapping the floor into software

The hardest work was translational, not cosmetic "tech." Supervisors don't narrate work as tables and foreign keys. They talk about things, places, and moves.

It took weeks of observation to internalize that a "batch" on knitting is not the same abstraction as a "batch" in dyeing. Same word, different meaning. Getting that wrong in the schema would have confused everyone.

We anchored the model on persistent material identity: a single identifier following stock through every stage, whatever each department called it. That gave the system one language that matched physical reality.

Raw, WIP, and finished goods in one coherent model

A garment plant isn't one warehouse. Raw materials, WIP at several stages, and finished goods coexist. Different rules, different views. The design had to keep them distinct (so a warehouse lead could read raw without wading through FG) while staying one coherent model in the backend and app layer.

Replacing habit with deliberate entry

The underestimated risk is people: moving teams from muscle memory and spreadsheets to explicit data entry.

Floor staff are not office workers; many had limited prior software use. The bar was practical: a supervisor should log production output in under ~30 seconds on a modest device, after short orientation.

That constraint drove UI and flow: drop non-essential fields, order steps to match physical sequence (not what looks tidy in ERDs), and use clear confirmation before save so errors are caught without CS degrees.

What building for manufacturing teaches you

Factory ERP forces you to design for someone under time pressure, in noise, attention split between screen and machine.

Office users sit, click, read errors, workaround. Floor users stand at lines and decide in real time. If the tool slows them, they drop it.

That pressure makes you sharper everywhere: when you've designed for the hardest users, easier contexts feel simpler.

It also reinforced a rule I still use: the best operational systems come from engineers who understand reality before they design abstractions. The floor taught us things no requirements PDF would have held. That gap is often what separates adopted software from abandoned software.

Closing

If you're building operations software for manufacturing, a plant, or any place where users aren't at desks, you're solving for adoption under constraint, not just features.

I've shipped at factory-floor depth, and I care about the difference between software that sticks and software that dies in the notebook shadow.

If this resonates, leave a comment with your own manufacturing or ERP war story, or reach out if you want to compare notes on what you're building.

Event-Driven Architecture: A Practical Guide with Real Example

Momin Ali — Wed, 01 Apr 2026 06:57:48 +0000

In modern software systems, tightly coupled architectures quickly become a bottleneck. As systems grow, managing dependencies, scaling services independently, and maintaining resilience becomes difficult.

This is where Event-Driven Architecture (EDA) becomes a powerful solution.

🚀 What is Event-Driven Architecture?

Event-Driven Architecture is a design pattern where services communicate through events instead of direct API calls.

An event is simply a record that something has happened in the system.

Examples:

UserRegistered
OrderPlaced
PaymentCompleted

Instead of calling another service directly, a service emits an event, and other services react to it.

🧠 Core Components

Event Producer → Generates events
Event Broker → Distributes events (Kafka, RabbitMQ, AWS SNS/SQS)
Event Consumer → Listens and reacts to events

⚙️ How It Works

A user places an order
The Order Service emits an OrderPlaced event
Multiple services react independently:

Payment Service processes payment
Inventory Service updates stock
Notification Service sends confirmation

No direct service-to-service calls.

🏗️ Traditional vs Event-Driven

❌ Tightly Coupled

Order Service → Payment Service → Inventory Service → Notification Service

Problems:

One failure breaks the chain
Hard to scale
High coupling

✅ Event-Driven

Order Service → emits "OrderPlaced"

Consumers:

Payment Service
Inventory Service
Notification Service

Each service works independently.

💻 Example (Node.js + Kafka)

Producer (Order Service)

const kafka = require('kafka-node');
const producer = new kafka.Producer(new kafka.KafkaClient());

const orderEvent = {
  event: "OrderPlaced",
  data: {
    orderId: "123",
    userId: "456",
    amount: 100
  }
};

producer.send([
  { topic: 'orders', messages: JSON.stringify(orderEvent) }
], (err, data) => {
  console.log(data);
});

Consumer (Payment Service)

const consumer = new kafka.Consumer(
  new kafka.KafkaClient(),
  [{ topic: 'orders' }]
);

consumer.on('message', (message) => {
  const event = JSON.parse(message.value);

  if (event.event === "OrderPlaced") {
    console.log("Processing payment for:", event.data.orderId);
  }
});

✅ Benefits

Loose coupling
Independent scalability
Better fault tolerance
Easy extensibility

⚠️ Challenges (Production Reality)

Eventual consistency
Debugging complexity
Message ordering
Duplicate events

Solutions:

Idempotent consumers
Distributed tracing (OpenTelemetry, AWS X-Ray)
Proper partitioning strategy
Retry + dead-letter queues

🧩 When to Use It

Use EDA when:

Building microservices
Need scalability and flexibility
Expect system growth

Avoid when:

System is small/simple
No async workflows needed

🧠 Pro Tip

Don’t over-engineer.

Use a hybrid approach (REST + Events) instead of forcing everything into events.

🔚 Conclusion

Event-Driven Architecture shifts your mindset:

From:
"Which service should I call?"

To:
"What event just happened?"

That shift helps you build scalable, resilient, and future-proof systems.

Context7: The Tool That Finally Fixes AI Coding Assistants

Momin Ali — Sun, 29 Mar 2026 09:16:33 +0000

Stop getting outdated code from your AI. Here's how Context7 injects live, version-accurate documentation straight into your prompts.

The Problem Every Developer Knows Too Well

You've been there. You ask your AI coding assistant — Cursor, Claude Code, GitHub Copilot — to help you set up authentication with Supabase, or write a Next.js middleware, or configure a Prisma schema. It generates code confidently and quickly.

Then you run it.

And it breaks.

You check the docs. The API it used was deprecated eight months ago. The method signature changed in the last major release. The import path doesn't even exist anymore.

This is one of the most frustrating friction points in modern AI-assisted development. Your AI is working from training data that was frozen at a certain point in time. It doesn't know what changed in version 14 vs version 15. It doesn't know that the team renamed that hook, moved that config option, or deprecated that pattern.

Context7 is built to solve exactly this problem.

What Is Context7?

Context7 is an open-source tool built by Upstash that pulls up-to-date, version-specific documentation and code examples directly from the source — and injects them straight into your AI's prompt context.

No more tab-switching. No more outdated API guesses. No more hallucinated methods that don't exist.

GitHub Repository: https://github.com/upstash/context7

With over 50,000+ GitHub stars and 2,400+ forks, Context7 has become one of the most widely adopted MCP servers in the AI developer tooling ecosystem.

How It Works

Context7 intercepts your library-related questions and enriches them with real documentation before they reach the LLM. Here's the core idea:

Without Context7

You: "Create a Next.js middleware that validates JWT tokens."

AI: [Generates code based on 18-month-old training data]
    [Uses deprecated `withMiddlewareAuthRequired` API]
    [You spend 45 minutes debugging why it doesn't work]

With Context7

You: "Create a Next.js middleware that validates JWT tokens. use context7"

Context7: [Fetches current Next.js middleware docs]
          [Injects version-specific examples into prompt]

AI: [Generates code using the correct, current API]
    [It works on the first try]

The difference is simple but enormous in practice.

Two Modes of Operation

Context7 gives you flexibility in how you integrate it into your workflow.

1. CLI + Skills Mode (No MCP Required)

This mode installs a "skill" — essentially a set of instructions that guides your AI agent to fetch live documentation using ctx7 CLI commands.

It's the lightest way to get started and works even if your AI client doesn't support MCP servers natively.

2. MCP Mode (Native Tool Integration)

This mode registers Context7 as a proper MCP (Model Context Protocol) server, so your AI agent can call documentation tools natively as part of its reasoning flow.

If you're using Cursor, Claude Code, or any MCP-compatible client — this is the recommended approach.

Getting Started in 60 Seconds

Setup is refreshingly simple:

npx ctx7 setup

This single command:

Authenticates you via OAuth
Generates a free API key
Installs the appropriate skill or MCP config for your agent

You can also target a specific client:

npx ctx7 setup --cursor      # For Cursor
npx ctx7 setup --claude      # For Claude Code
npx ctx7 setup --opencode    # For OpenCode

Pro Tip: Get a free API key at context7.com/dashboard for higher rate limits.

Real-World Usage Examples

Once installed, you simply add use context7 to any prompt involving a library:

Configure a Cloudflare Worker to cache JSON API responses for 5 minutes. use context7

Show me the Supabase auth API for email/password sign-up. use context7

Set up Prisma with PostgreSQL and generate the initial migration. use context7

Context7 resolves the library, fetches the correct version's documentation, and enriches your prompt — all transparently.

Targeting a Specific Library

If you already know the exact library you need, use its Context7 ID to skip the resolution step:

Implement row-level security with Supabase. use library /supabase/supabase

Targeting a Specific Version

Need docs for an older or specific version? Just mention it:

How do I configure layouts in Next.js 13? use context7

Context7 will match the appropriate version's documentation automatically.

Available Tools

CLI Commands

Command	Description
`ctx7 library <name> <query>`	Search the Context7 index for a library by name
`ctx7 docs <libraryId> <query>`	Fetch documentation for a specific library

MCP Tools

Tool	Description
`resolve-library-id`	Resolves a library name into a Context7-compatible ID
`query-docs`	Fetches documentation for a given library ID and query

Why This Matters More Than You Think

As a developer, you might think: "I can just check the docs myself."

You can. But consider this:

Speed — The whole point of AI coding assistance is velocity. Manually cross-referencing docs defeats the purpose.
Reliability — AI hallucinations on APIs are subtle. The code looks right. It often compiles. It only fails at runtime or in edge cases.
Cognitive load — Keeping library versions and API changes in your head while also solving business logic is expensive mental overhead.
Team consistency — On a team, different developers may be working with different versions. Context7 standardizes what the AI generates.

Context7 essentially makes your AI coding assistant production-aware instead of training-data-aware.

Add a Permanent Rule to Your Agent

The most powerful way to use Context7 is to set it as a default rule in your coding agent — so it activates automatically without needing to type use context7 every time.

For Cursor: Cursor Settings > Rules

For Claude Code: Add to CLAUDE.md

Suggested rule:

Always use Context7 when I need library/API documentation,
code generation, setup or configuration steps — without me
having to explicitly ask.

Once this is in place, your AI will silently fetch up-to-date docs on every relevant question. It becomes invisible infrastructure.

Tech Stack & Open Source Details

Language: TypeScript (89.6%), JavaScript (10%)
License: MIT
Contributors: 113+
Stars: 50,300+
Maintained by: Upstash

The repository is fully open source. The MCP server source code is public, though the supporting API backend, parsing engine, and crawling infrastructure are private.

🔗 Explore the source: https://github.com/upstash/context7

Supported Clients

Context7 supports 30+ clients. Some of the most popular include:

Cursor
Claude Code
GitHub Copilot
OpenCode
VS Code with Copilot
Windsurf
Gemini CLI

Full list available at context7.com/docs/resources/all-clients.

Final Thoughts

AI coding assistants are powerful. But they're only as good as the information they work with. Stale training data is a silent productivity killer — you don't always know the AI is wrong until you've already spent time debugging.

Context7 closes that gap. It's lightweight, easy to set up, and integrates cleanly into your existing workflow. Whether you're a solo developer building a SaaS product or part of a large engineering team, the ROI on setup time is almost immediate.

If you use any AI coding assistant regularly, Context7 is one of those tools you install once and wonder how you lived without it.

🔗 Links:

🌐 Website: https://context7.com
💻 GitHub: https://github.com/upstash/context7
📦 NPM: @upstash/context7-mcp
💬 Community: Upstash Discord

Have you tried Context7? Drop your experience in the comments below. I'd love to hear how it's working in your workflow.