Recovering delivery while modernizing two public-sector applications

The delivery problem was larger than the stack

I joined a public-sector program used to submit and process work-study contracts. Delivery had accumulated a three-month gap, recurring stability problems, expensive data paths, and framework and infrastructure obsolescence. The work crossed two connected applications: one based on Node.js and React, the other on Java and Angular.

I joined as Tech Lead and led two developer teams across the connected applications. My role combined hands-on implementation with mentoring, recurring 1:1s, competency planning, pair programming, code reviews, delegation, estimates, prioritization, release planning, business validation, and client communication.

I also supported the project manager with planning, delivery, and risk escalation. The scope expanded into architect-level responsibilities across infrastructure decisions, impact studies, modernization, and cross-application technical ownership. In 2024, I was considered internally to be operating at architect level; my historical title remained Senior Full-Stack Engineer and Tech Lead.

Stabilization before more scope

I separated high-priority defects from feature expansion and made stabilization visible in the plan. Releases moved through short development, business-validation, stabilization, retest, and client-delivery cycles instead of a one-shot handoff.

Estimates included analysis, implementation, automated tests, business validation, and stabilization. When requirements or hidden business rules were unclear, I escalated the uncertainty before committing the date rather than leaving the team to absorb it at the end.

This combination of prioritization and technical delivery helped the team deliver a three-month delayed priority backlog plus one month of planned product evolution in two months. The recovery restored client confidence and led to responsibility for the second connected application.

Modernizing in stages

I did not bundle the technology debt into one high-risk rewrite. Upgrades were sequenced across releases and verified at each step:

• Node.js 14/16 to 20, Next.js 12 to 14, and React 17 to 18.
• Angular 13 to 17 and PostgreSQL 11 to 15.
• Java 8 to 17, Spring Boot 2.6 to 3.3, Tomcat 9 to 10, and Elasticsearch 7 to 8.

The work included dependency-impact studies, build and pipeline repairs, data migration and rollback procedures, regression testing, operating documentation, technical demonstrations, and pair programming. Delegating feature ownership did not remove release accountability: I retained cross-application review and validation.

A bounded performance result

Several high-volume interfaces were loading more data and executing more database work than the user needed. I indexed search fields, simplified heavy queries, filtered earlier, returned only required fields, and isolated malformed records so one bad item could not block an entire interface.

For a representative preproduction workspace containing 100 contracts:

• database requests fell from 201 to 3;
• response time fell from 7.69 seconds to 46 milliseconds;
• payload size fell from 6.3 MB to 37.1 kB.

Those numbers belong to one preproduction workflow, not every request in the product.

Product movement during the engagement

The measured dematerialization rate rose from 50% in 2022 to 90% in 2024. The 2024 record shows 9,000 of 10,000 submissions flowing through the application. I treat that as engagement-period product movement rather than claiming the engineering work alone caused the full adoption increase.

What remains private

The public-sector client and application names, internal tickets, team-member identities, repositories, hosts, credentials, operational data, and detailed security findings are excluded. The case demonstrates technical and delivery leadership; it does not claim a formal Architect promotion, enterprise-wide architecture authority, formal line-management authority, or sole delivery of the team outcome.