Case study 01
Client modernization · solo product engineering
Reconstructing an undocumented fixed-asset workflow for a 40-year-old finance firm, then rebuilding it around traceable physical assets and authoritative financial controls.
The firm relied on an aging .NET and MySQL application with weak search, one-form-at-a-time navigation, limited correction workflows, and no practical way to follow an asset through purchase, custody, depreciation, verification, and disposal.
Requirements were spread across an old executable, incomplete table documentation, operator habits, accounting rules, and organizational memory. My first Flutter prototype modeled the lifecycle incorrectly, which made the real task clear: I had to reconstruct the business system before I could replace its screens.
The finished architecture makes more sense when the discoveries, reversals, and responsibility shifts are visible.
I interviewed the data-entry operator and team, built a one-week lifecycle prototype, and used its rejection to expose gaps that verbal requirements had hidden.
After restoring obsolete dependencies and MySQL tooling, I studied the running system to understand master data, transactions, disabled paths, and the workflow users could not fully articulate.
Purchase became the ownership event, allocation became custody, and labels gave each physical unit a lifecycle that could diverge from identical units on the same invoice.
Depreciation became a preview, Excel verification, and posting workflow with separate histories for each label and accounting treatment.
The reports mixed defects, regressions, usability requests, and newly explained business rules. I serialized the decision changes, continued through February, and brought the 104-item backlog to approximately 94% creator-reported closure.
Each choice connects a business constraint to an implementation boundary and retained evidence.
A purchased asset can remain unallocated, be returned, or move between employees without rewriting the purchase that established ownership.
Evidence · Purchase, allocation, reallocation, and reversal are represented as distinct lifecycle events.A purchase header groups the invoice, line items carry asset economics, and labels identify each physical unit so identical assets can develop different histories.
Evidence · Allocation, depreciation, verification, sale, and scrap operate at label level.The workbook stays familiar to accountants while the application validates formats, resolves existing masters, creates missing dependencies in order, and batches purchase creation.
Evidence · The benchmark imports approximately 1,000 procurement records and 40 related master records in about 20 seconds.Calculation, human verification, and financial mutation are separate stages. Multi-year previews remain sequential without forcing users to post each year manually.
Evidence · The product exposes preview, Excel export, per-label histories, and controlled posting.Flutter requests and presents calculations; the backend resolves rules, lifecycle state, and posted history so results do not depend on a particular client build.
Evidence · Financial calculation and persistence moved from the Flutter client into Spring Boot services.Open any diagram at its original resolution to inspect the complete workflow.
Open full resolution ↗
Open full resolution ↗
Open full resolution ↗Selected screens show how the lifecycle model became an operator-facing product, from procurement and custody through calculation, verification, reporting, and disposal.
Open source gallery ↗Architecture is only part of the story. These constraints changed how I implemented, tested, and recovered the product.
Purchase and allocation files grew toward 20,000 lines as product discovery and delivery happened together. Repeated large rewrites failed; smaller AI-assisted extractions reduced entanglement incrementally while preserving behavior.
Ordered resolution, DTOs, bounded batches, joined queries, caching, and virtualized tables avoided loading the entire working set or issuing per-row lookups.
The preserved tracker records 88 solved, eight partially solved, six not solved, and two other entries at its final saved snapshot. Later work brought the 104-item backlog to approximately 94% creator-reported closure, while the historical register remains unchanged.
The working system spans purchasing, allocation and reallocation, depreciation, sales and scrapping, physical verification, reporting, audit logs, and supporting master data.
Across a UAT register that mixed defects, regressions, feature requests, and late business-rule changes, I drove approximately 98 of 104 tracked items to closure—about 94%—after the surviving tracker stopped being updated.
Seventeen master-data reports plus the Fixed Asset Register, Fixed Asset Movement Register, Purchase Register, Sale Register, and Scrap Register were reviewed with test data.
Evidence boundary. The 94% figure describes mixed UAT backlog closure, not an automated test pass rate. The surviving tracker directly records the earlier snapshot; the final closure includes later fixes reported by me. I did not retain evidence of client production adoption or regulatory submission, so neither is claimed.
Evidence basis
AI disclosure. AI tools generated or revised portions of application code, tests, scripts, and documentation within directed implementation workflows and under source review. I owned client discovery, requirements, architecture, module boundaries, prompting direction, source review, debugging, validation evidence, UAT remediation decisions, and release and maintenance decisions.