The Problem

In a large banking organization, the transaction and contract lifecycle — from request registration through contract execution — was scattered across dozens of forms and approval paths. The goal was a single platform covering that entire cycle, deployed inside the bank's internal network.

My Role

Product owner for several modules and senior backend developer. Architecture design, data modeling, and delivery from the ground up to UAT in seven months with a three-person team.

Architecture & Technical Decisions

• 148 business modules built on CQRS with MediatR, over Clean Architecture and DDD in .NET 8 — each module with clear boundaries and minimal coupling to the rest.
• A 930-table domain model on EF Core 8 with 316 migrations; more than 3,500 REST endpoints.
• Role-based access control with endpoint-level granularity, JWT authentication, and AES encryption — meeting the requirements of a banking environment.
• MassTransit over RabbitMQ for asynchronous events, Redis-backed SignalR for real-time, and Hangfire for scheduled processing — keeping heavy work off the user request path.
• On-premise deployment inside the bank's closed network, with no access to cloud services.

Challenges

• Delivering a domain of this size with three developers. The answer was a spec-driven pipeline: 14 codified engineering-convention skills, 379 specification documents, and a requirements → data model → design → staged build → automated audit cycle. The team sustained roughly 300 commits per month.
• Holding quality at that pace. Close to 6,000 xUnit tests alongside Playwright and Vitest end-to-end coverage, under GitHub Actions CI on every pull request.

Outcome

The platform is in UAT at a national bank. The entire domain — from data model to user interface — was built in seven months by three people.

Stack

• .NET 8
• C#
• MediatR
• EF Core 8
• SQL Server
• MassTransit
• RabbitMQ
• Redis
• SignalR
• Hangfire
• React 19
• TypeScript
• MUI
• xUnit
• Playwright
• GitHub Actions

The Problem

Requirements, bug reports, and suggestions from end users arrived through scattered channels, and turning them into actionable work for the development team was manual and slow.

My Role

Designed and built the entire system, from data model through integrations to the supporting infrastructure.

Architecture & Technical Decisions

• A two-stage review workflow: a technical reviewer and a business reviewer each comment on every ticket, and nothing enters the development queue until both approve.
• Approved items are connected to Claude Code through MCP as structured specifications — automating the path from end-user request to the start of development.
• Active Directory integration for admin authentication.
• Telegram and Bale bots for automatic ticket creation and task generation in Azure TFS.

Challenges

• The system needed transactional email and there was no infrastructure for it. Rather than depending on an external service, I deployed a Stalwart mail server on Windows Server — with DNS, SPF/DKIM/PTR configuration and an IIS reverse proxy.

Outcome

Requirement intake, from end user to the start of development, is now effectively automated.

Stack

• .NET
• SQL Server
• MCP
• Claude Code
• Active Directory
• Azure TFS
• Telegram Bot API
• Stalwart
• IIS

The Problem

Contractual and project information in a large government organization lived in separate systems; cost estimation, payment approval, and warehouse consumption each followed their own path, leaving no unified picture of project status.

My Role

Analysis, design, and implementation of the core modules: budgeting, cost estimation, warehouse management, payment approval, and WBS.

Architecture & Technical Decisions

• Cross-module logical controls mapped to the client's real administrative processes — not a generic model.
• Operational dashboards and management reports for real-time monitoring of key project indicators.
• Secure development practices focused on access control, data integrity, and traceability, accounting for AFTA requirements.

Outcome

The system is deployed and running at the National Iranian Gas Company.

Stack

• C#
• ASP.NET
• SQL Server
• BPMS

The Problem

Managing the transaction and contract lifecycle in large organizations, from request registration through contract execution, with complex administrative workflows that differ for every client.

My Role

Developed core backend modules and redesigned workflows on an internal BPMS engine.

Architecture & Technical Decisions

• Workflows implemented on the company's internal BPMS engine, with BPMN modeling matched to each client's actual process.
• On-premise deployment inside clients' internal networks.
• Security hardening for AFTA compliance — access control, secure API design, input validation, and audit readiness.

Outcome

The system is deployed at Nouri Petrochemical, Pardis Petrochemical, and Bank Tejarat.

Stack

• C#
• ASP.NET
• SQL Server
• BPMS
• BPMN
• SOAP
• REST

The Problem

Placing garment pattern pieces on a fixed-width roll of fabric so that the least possible length is consumed. In the literature this is two-dimensional irregular strip packing, and it is NP-hard — no algorithm can guarantee the optimal answer in reasonable time. Every percentage point of improvement in utilization is a direct reduction in fabric waste.

My Role

Rewrote the layout optimization engine and modernized the application's runtime platform.

Architecture & Technical Decisions

• The new engine moved to Rust and runs out-of-process, communicating with the .NET host through a schema-defined JSON contract. The benefit is isolation: if the solver hangs or crashes, only the child process dies, not the application.
• No-Fit-Polygon computation moved from a hand-written implementation (edge merging with convex/concave classification) to exact Minkowski sums on the industrial Clipper2 library — eliminating the main source of numerical error in the old version.
• Instead of accepting the first valid position (Bottom-Left-Fill), the new solver generates several candidate placements and picks the best based on contact with neighboring pieces.
• Multi-start construction across seven different sort strategies, then improvement by local hill-climbing — lighter and faster than the old version's genetic algorithm.
• A dual stopping criterion: a user-configurable time budget plus stall detection, letting the user set the quality/time trade-off directly.
• The host component was migrated from .NET Framework 2.0 to .NET 8.

Challenges

• Hardware fingerprints did not match across the two runtimes: the legacy component on .NET Framework 2.0 and the new one on .NET 8 returned different values despite reading the same WMI data. Root-cause analysis involved comparing IL between the two builds and running the algorithm by hand against real user data; the cause was a package missing from the transitive dependency graph, and the fix was a single line in the project file.
• The Persian UI kept falling back to English even though the culture was set correctly. The first two hypotheses were both wrong; the real cause was a CLR version mismatch between the resource satellite assemblies and the host CLR, which silently fell back to the neutral resources. Fixed by rebuilding the satellites with the matching compiler and adding an automated assertion before packaging.

Outcome

Fabric utilization rose from 78% to 85%, and runtime dropped from 17 hours to under 2 minutes.

Stack

• Rust
• Clipper2
• .NET 8
• .NET Framework 2.0
• C#
• WinForms
• JSON Schema
• Inno Setup

The Problem

Automating repetitive Telegram tasks and building a testbed for integrating with external services.

My Role

Development and customization on top of an open-source base, plus the full deployment path.

Architecture & Technical Decisions

• Dual-client architecture: a user account and a helper bot account running concurrently, with 42 feature plugins across five distinct subsystems.
• Integrations with Azure Cognitive Services (Speech), Google Drive, Google Translate, and several other services.
• User-ID-based authorization, with no dependency on traditional auth infrastructure.

Challenges

• Resolving a runtime dependency conflict between a custom fork of the core library and its upstream package — handled with an explicit build-time check that fails the build if both are installed.

Outcome

Fully containerized with Docker Compose and deployed to a production VPS with log rotation.

Stack

• Python 3.10
• Docker
• Docker Compose
• SQLite
• Telegram MTProto
• Azure Speech
• Google Drive API