Domain Model
The purchase module was rebuilt around physical asset units instead of purchase rows alone. That made labels, allocation, depreciation, and verification possible as connected workflows.
What made it hard
Not a rewrite. A recovery.
FAMS was a recovery engagement after earlier delivery attempts had not reached completion. That changed the nature of the work: the software, stakeholder confidence, 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 with established operating practices.
The buyer was a long-running business services and software firm with deep operational exposure across fixed asset accounting, payroll, finance workflows, HR operations, outsourced business processes, and advisory-style support. The engagement required sensitivity to established internal practices without exposing client identity or private operating details.
That context mattered because the system was evaluated by a team with direct experience in fixed asset accounting, proprietary software, payroll, finance workflows, and outsourced business operations. The bar was not just interface completeness; 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 the fixed asset platform. 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
Delivery reset
A status review clarified the remaining work and reset the delivery plan around a November 30 target, moving the engagement into an intensive implementation phase.
Oct-Nov 2025
Transaction build and performance tuning
Purchase, allocation, sale, scrap, impairment, depreciation voucher, reports, and key transaction screens were completed. A major page-load bottleneck 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.
This engagement shaped Codeforge's delivery model for scoped, compliance-heavy ERP work.
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, acceptance criteria, and documented decisions.
Outcome
Why this case matters
FAMS represents the operating standard Codeforge now applies to serious ERP work: scoped modules, domain review, architectural ownership, performance gates, documentation, UAT governance, and clear closure controls.