Internal technical walkthrough · dotdev.dev

Keep the evidence visible when a dependency fails.

A small rendering boundary on this website illustrates how I scope a reliability fix: preserve the content that works, isolate the failure and make recovery available.

The problem

The Projects page combines curated project cards with a live list from GitHub. In the original implementation, loading and error returns came before both sections. If GitHub failed, visitors lost the static AgentWire and Playchek links as well.

The constraint

The curated portfolio did not need GitHub to render. The repository list did. The fix needed to respect that distinction without introducing a backend, caching service or a new page architecture.

The work

Move request status into its own section. Bound how long the request can remain pending. Cancel obsolete requests when the page unmounts. Keep the list’s scope honest: it shows the latest 30 public repositories, and its filters apply to that set.

How to verify it

The browser regression suite controls GitHub responses rather than waiting for a real outage. It checks featured links during failure, a retry that succeeds and an empty response. The same page is reviewed at mobile and desktop sizes.

• Inspect the page implementation
• Read the browser checks
• Try the portfolio page

What this demonstrates

A dependency failure can be contained at the part of the interface that depends on it. This is an internal example, not a client case study. No conversion lift, revenue impact or time-saving figure has been measured or claimed.