Case Study 01 · Work completed at Alpaca Systems
Modernizing a slow operational platform across the full stack
How diagnosis across data access, APIs, rendering, and caching turned slow core workflows into responsive production software.
Outcome
Reduced workflows that commonly took more than 30 seconds to a few seconds initially, with near-instant cached revisits.
Role and context
What I owned
- Formal title
- Full-Stack Developer
- Project responsibility
- Project technical lead in practice for modernization of core workflows.
- Team context
- Worked within a product team alongside design, QA, DevOps, and other developers.
- Personally owned
- Diagnosis, data-flow redesign, API changes, caching strategy, rendering corrections, implementation plans, and technical documentation.
- Collaborator ownership
- Design shaped the revised interaction flows; QA and DevOps supported validation and release delivery.
The operational problem
Software had to match the way the work moved.
Personnel, equipment, and form-management workflows in an enterprise safety and compliance platform commonly took more than 30 seconds to become usable.
Constraints that mattered
- The platform was already in production and had to continue serving active operational workflows.
- Modernization needed to proceed incrementally rather than through a full rewrite.
- Existing data shapes and client-specific behavior limited how aggressively contracts could change at once.
Before
>30s
After
A few seconds
Diagnosis
Find the system behind the symptom.
- 01
Traced latency through database access, backend processing, response payload size, and frontend rendering.
- 02
Separated first-load cost from repeat-navigation cost so caching behavior could be evaluated honestly.
- 03
Identified broad routes and client-side processing that transferred too much work to the browser.
Decision log
The choices and their costs.
01
Narrow the data boundary
Moved expensive filtering and shaping toward query-focused backend routes with smaller responses and pagination where appropriate.
Trade-off
More explicit API contracts created additional backend work, but reduced repeated transfer and browser processing.
02
Adopt a shared server-state cache
Introduced Redux Toolkit Query for request lifecycle, cache reuse, invalidation, and loading-state consistency.
Trade-off
The team had to learn a new data-fetching pattern and migrate incrementally alongside existing state.
03
Correct rendering behavior
Reduced unnecessary recomputation and rerendering in high-traffic screens after the data path was made leaner.
Trade-off
UI optimization alone would not have solved the problem, so it followed rather than replaced backend work.
What changed
Result and evidence
- Core workflows became practical for repeated daily use instead of forcing long waits.
- The architecture provided clearer ownership between server state, client state, and presentation.
- The modernization created a foundation for later workflow improvements without a disruptive rewrite.
Evidence quality
Timing language is based on observed production behavior and retrospective reconstruction, not a preserved benchmark suite. The distinction between initial and cached loads is intentional.
Reflection
What I would improve today
Today I would establish repeatable route-level and browser performance checks earlier, record representative datasets, and add performance budgets to prevent regressions as the product evolved.
This Case Study is a sanitized account of work completed at Alpaca Systems. Product and client names are withheld. Visuals are original conceptual explanations using invented data; no former-employer screenshots, source code, schemas, or proprietary diagrams are shown.