Web Applications
Web intake for a VB6-era loan administration system
Built by Leandro Magbanua
Put a web intake front end on a 2003 loan admin system whose database schema was frozen until fiscal year-end — without touching a single existing table.
Builder email verified
Verification
- Type
- Professional
- Category
- Web Applications
- Published
- Jul 26, 2026
- Updated
- Jul 26, 2026
About this project
- The problem
Branch staff encoded loan applications directly into a VB6 desktop application from 2003, which meant a branch could only process applications as fast as its one trained encoder, and errors surfaced days later as a printed exception report. The business wanted web-based intake so any officer could start an application, but the system's SQL Server schema was declared untouchable until the fiscal year closed — a previous project had modified a table mid-year and finance was still telling the story.
- My role
Senior backend developer and the informal technical lead for the integration approach, on a team of four, for about eleven months. I answered to a product owner from the lending group who wanted features and a database administrator who wanted the legacy schema left alone; most weeks my actual job was designing things both of them could live with.
- What I owned
I owned the integration layer: a set of staging tables in a separate schema that the web intake wrote into, the validation service that enforced the legacy system's undocumented rules before submission, and the nightly synchronization job that posted completed applications into the VB6 system's tables through the same stored procedures the desktop app used. Reverse-engineering those procedures — and the rules that lived only in VB6 form code — was most of the work.
- Technical & product decisions
The load-bearing decision was refusing to write to the legacy tables directly, even though direct writes would have been faster to build. Posting through the system's own stored procedures meant its triggers and audit columns behaved exactly as if a desktop encoder had typed the application, which kept the DBA onside and made rollback trivial — delete from staging, nothing entered the real system. I also replicated the legacy validation into our service rather than waiting for the nightly job to reject records, after the pilot branch made it clear that 'your application failed overnight' is not an acceptable answer to give an applicant who was sitting in the branch.
- Constraints
The schema freeze was absolute and outlasted the project's original schedule. The VB6 source compiled only on one machine in the office, which became a shrine nobody was allowed to update. And the pilot had to run in one branch for a full month before the change advisory board would discuss wider rollout, which forced us to build proper feature gating instead of the big-bang release the product owner originally wanted.
- Result & impact
The pilot branch cleared its application backlog in three weeks, mostly because any officer could now start an application while the encoder handled only final review. Validation errors came back to the person typing, on the same screen, instead of on the next day's printed report — the exception report shrank from pages to a handful of lines. Rollout reached all 23 branches over four months, and when the fiscal year finally closed, the staging-table design meant the eventual schema changes were an optimization, not a rescue.