You have built your web application carefully. It renders perfectly on your development machine, behaves consistently across browsers, and passes every test you throw at it. Then it lands in a client environment, and suddenly something subtle but critical is missing.
Icons
Buttons still exist. Layouts still hold. But where there should be clean, professional iconography, there are only empty squares. It looks like a rendering glitch, perhaps a CSS issue, but it is neither.
This is not a bug in your code. It is the network quietly working against you.
Modern frontend development makes it very easy to pull in polished UI assets. A single line like this feels harmless:
<link href="https://cdn.jsdelivr.net/npm/bootstrap-icons@1.11.0/font/bootstrap-icons.css" rel="stylesheet">And just like that, you have a full icon library.
But what appears to be a single dependency is actually a chain of requests. The browser first fetches the CSS. Lightweight, harmless, and almost always allowed through. Then, inside that CSS, there is a second request:
src: url("./fonts/bootstrap-icons.woff2") format("woff2");That .woff2 file is the real payload, the font that actually renders the icons.
And in many enterprise environments, that is exactly where things fall apart.
On your machine, everything works because nothing is restricted. Inside corporate networks, shopping malls, and retail infrastructure, things are very different.
Firewalls and proxies are often configured conservatively. They do not just filter obvious threats, they restrict anything unfamiliar or unnecessary. That frequently includes:
font/woff and font/woff2The result is simple.
The CSS loads. Your HTML applies the correct classes. But the font file, the part that actually draws the icons, never arrives.
There are no obvious errors. No stack traces. No helpful warnings.
Just empty squares.
The solution is not to fight the firewall or ISP. It is to make them irrelevant.
Instead of relying on the client’s browser to fetch external assets, bring everything inside your own application boundary. Download once, serve locally, and remove the dependency entirely.
.woff2 and .woff font filesThe result is predictable, self-contained behaviour. No outbound requests, no dependency on external infrastructure, and no missing icons.
This issue highlights a deeper truth about software deployment. Your development environment is the least restrictive environment your application will ever run in.
Enterprise environments are designed with different priorities such as control, security, and predictability. This creates a gap where subtle dependencies can break:
These are not obvious failures. They are quiet degradations.
And they are exactly the kind that slip through testing.
If your application is going to run inside someone else’s network, the safest assumption is simple:
Nothing outside your application boundary is guaranteed to be reachable.
That means:
Bundle your assets Do not rely on CDNs for critical UI components
Self-host dependencies If your application needs it, ship it with the application
Audit external calls Every external URL is a potential failure point
Design for isolation Your application should function fully without internet access
Because if your application needs to step outside to work, it will eventually land somewhere it cannot.
At Prometheus Systems, we design systems with real-world deployment environments in mind, not ideal ones. The goal is always the same: predictable, reliable operation regardless of where it runs.
If your application behaves perfectly in development but breaks in production, the issue may not be your code. It may be the environment you did not account for.
Seeing missing assets or unusual UI behaviour inside a corporate or retail network? Prometheus Systems can help you identify and eliminate hidden dependencies before they become operational problems. Reach out to learn more.
