Domain Model
The purchase module was rebuilt around physical asset units, not only purchase rows. That made labels, allocation, depreciation, and verification possible as connected workflows.
What made it hard
Not a rewrite. A recovery.
Before Codeforge Labs took on FAMS, two earlier teams had attempted to deliver the project and failed to bring it to completion. That changed the nature of the engagement. This was not a clean greenfield build with perfect requirements. It was a recovery project where the software, client trust, legacy behavior, compliance expectations, and delivery process all had to be rebuilt together.
The old system was built around fixed asset workflows that were familiar to the client team but difficult to reproduce cleanly: purchase transactions, individual asset labels, allocation and reallocation, sale, scrap, impairment, depreciation, reports, and physical verification. Copying the old system would have preserved the same problems. Rebuilding it meant understanding the business rules underneath it.
Client context
Domain-heavy buyer, not a generic SME.
MCS Computer Services Pvt. Ltd. is a Delhi-based software and business solutions company incorporated in 1982. Public company records list Anshuman Dutta and Navin Bhagat among the directors, with the registered address in Jangpura, New Delhi. The firm has operated in business services for decades, with domain exposure across customized software, payroll, TDS, fixed asset accounting, HR and finance outsourcing, and advisory-style support.
That matters because FAMS was not being delivered to a naive buyer. It was being evaluated by a company that already understood fixed asset accounting, proprietary software, payroll, finance workflows, and outsourced business operations. The bar was not just "does the app open?" The system had to survive domain review, UAT, depreciation checks, imports, reports, and operational comparison with years of existing practice.
How the work moved
From legacy behavior to enterprise logic
Mar 2025
Structured review begins
Sanjay introduced a five-phase review and redesign approach for MCS Fixed Assets. Legacy documents, screenshots, and workflows were gathered before active rebuild work began.
Apr 2025
Contracted rebuild
The software development contractor agreement was signed. The build moved from exploration into a formal Flutter, Spring Boot, and PostgreSQL implementation.
May-Jul 2025
Reverse engineering and core modules
The old system was mapped into master modules, transaction modules, reports, QR flows, purchase, allocation, disposal, and depreciation workflows.
Sep 2025
Reality check and reset
A status review found the project far behind the required finish line. The deadline was extended to November 30, and the work shifted into an intensive delivery phase.
Oct-Nov 2025
Transaction build and performance rescue
Purchase, allocation, sale, scrap, impairment, depreciation voucher, reports, and key transaction screens were completed. A severe page-load issue was reduced from around 60 seconds to under 3 seconds through server-side pagination.
Jan-Mar 2026
UAT, release notes, and closure controls
The project entered structured UAT: release versions, defect lists, acceptance limits, depreciation verification sheets, installer packaging, rollback decisions, and closure definitions.
The project forced Codeforge to stop behaving like a coder and start behaving like a delivery organization.
Compliance Logic
Depreciation had to support Company Act SLM, Income Tax Act SLM and WDV, UOP cases, sale, scrap, residual values, put-to-use dates, and agreed UAT test cases.
Delivery Governance
The project produced a formal closure playbook: phase definition, blocker vs non-blocker defects, deferred scope, release notes, installer handoff, and written sign-off triggers.
What shipped
Functional scope
- 17 master modules and 8 transaction modules.
- Purchase, allocation, reallocation, sale, scrap, impairment, depreciation voucher, and verification workflows.
- Fixed Asset Schedule, Movement Register, Purchase Register, Sale Register, Scrap Register, and master reports.
- QR and barcode flows for asset identity and physical verification.
- Installer packaging, database setup scripts, changelogs, and UAT documentation.
What changed internally
Delivery lessons
- Scope must be frozen as feature tables, not loose prose.
- UAT must run against an agreed checklist, not shifting memory.
- Every defect needs severity, reproduction steps, expected behavior, and closure decision.
- Performance and data integrity issues must be treated as release gates.
- Commercial closure depends on evidence, not only effort.
Outcome
Why this case matters
FAMS is the strongest Codeforge case study because it proves more than coding ability. It shows recovery after failed attempts, enterprise domain learning, architectural ownership, stakeholder pressure, performance tuning, documentation, and UAT governance. The system became the reference project for how Codeforge now scopes, builds, tests, and closes serious software work.