Enterprise Desktop App — Startup and Size
30–40 s → 5–10 s startup, 25–30% smaller
An enterprise jewellery management platform that took over half a minute to open, traced to eager loading and duplicated UI, then rebuilt around lazy loading and shared components.
- Senior .NET developer — analysis, implementation
- 30–40 s → 5–10 s
- −25–30%
- ~5×
Problem
Staff opened this application at the start of a shift and waited 30 to 40 seconds looking at a splash screen. It is easy to file that as cosmetic. It is not: on a shop floor, a slow start gets worked around, and the workaround is leaving the app open all day, which turns a startup problem into a memory and stale-state problem.
Diagnosis
Two causes, and the second was invisible until the first was fixed.
Everything loaded eagerly. The application constructed its full object graph and fetched reference data for every module at launch — including modules a given user had no permission to open. The POS user was paying the cost of the manufacturing module.
The UI was duplicated rather than shared. Multiple near-identical screens had been copied and diverged slightly. That inflated the binary, and it multiplied the eager initialisation, because each copy initialised itself.
What I changed
Deferred construction to first use. Modules initialise when opened, not at launch. The startup path shrank to authentication, shell and the user’s default screen.
Reworked data access at startup. Reference data is fetched on demand and cached per session, rather than fetched wholesale up front. Most of it was never read in a given session.
Consolidated the duplicated screens into reusable components, and unified the copied point-of-sale variants into a single POS module. This is what produced the 25–30% size reduction — and it also removed the multiplied initialisation, which was the larger share of the remaining startup cost.
Result
Startup fell to 5–10 seconds and the application got 25–30% smaller. The size reduction was a consequence of the consolidation, not a separate effort.
Why this one is here
The stack is not what I work in now, and the domain is not financial. It earns a place because the shape of the problem is the one I keep meeting: the cost was work being done that did not need to happen at all, not work being done slowly. Deferring and de-duplicating beat optimising, and the same instinct is what produced the win on the payment distribution engine two years later.