Case Study
Rebuilding Our Own Foundation
How Zapex took its own website from broken to boardroom ready, and why that matters for your business.
The Situation
Every modernization firm says the same thing: we build fast, accessible, reliable systems. We decided to prove it on the one system we could not outsource the blame for. Our own site.
When we started, zapextech.ca had real problems hiding behind a polished design.
- 21 accessibility errors flagged by independent WCAG testing, including text that failed basic contrast standards for anyone with low vision.
- A broken contact form. Visitors saw a message received confirmation, but the email never arrived.
- A performance blocking intro animation that forced every visitor to sit through a 5 second branded sequence before seeing real content, severe enough to break Google's own performance measurement tools on desktop entirely.
- Render blocking font loading that added a full second or more to mobile load times on slower connections.
- Structural markup issues, including skipped heading levels, ambiguous link text, and missing semantic structure that made the site harder to navigate for screen reader users and search engines alike.
The Work
We ran a full audit to fix cycle using the same process we run for clients. Automated testing, manual verification, systematic remediation, and re-testing after every change. Because a fix that is not verified is not a fix.
Accessibility
- Traced every low contrast color back to its source and corrected the underlying design tokens, not just the symptoms.
- Fixed skipped and duplicated heading levels so screen reader users can navigate the page structure correctly.
- Rewrote ambiguous, duplicate link text into distinct, meaningful labels.
- Repaired broken internal anchor links left over from an earlier page restructure.
Performance
- Identified and fixed a hidden intro animation that was blocking the page's Largest Contentful Paint measurement entirely on desktop.
- Migrated font loading from an external Google Fonts request to self hosted, build time fonts, eliminating a render blocking network round trip on every page load.
- Reduced the intro animation to play once per session instead of on every visit, cutting real first load time for repeat visitors.
Reliability
- Diagnosed and repaired a silently broken contact form. Submissions were succeeding on the frontend but failing to deliver.
- Rotated and properly secured exposed API credentials.
- Verified the full email delivery pipeline end to end, not just the success message.
The Results
| Metric | Before | After |
|---|---|---|
| WCAG accessibility errors (WAVE) | 21 | 0 |
| Accessibility AIM Score | 5.5 / 10 | 10 / 10 |
| Lighthouse Accessibility | — | 100 / 100 |
| Lighthouse Best Practices | — | 100 / 100 |
| Lighthouse SEO | — | 100 / 100 |
| Desktop Performance | Failed to measure | 94 / 100 |
| Mobile Speed Index | 6.1s | 5.0s |
| Contact form | Silently broken | Fully working, verified end to end |
Why This Matters to You
This was not a redesign. The visual identity, the copy, the layout, all of it stayed the same. What changed was everything underneath. The parts a visitor never consciously notices, but that determine whether they can actually use your site, whether Google ranks it fairly, and whether the leads it generates actually reach you.
That is the same work we do for Calgary businesses running legacy systems that look fine on the surface. A booking tool that quietly drops half its submissions. An internal dashboard that is technically working but unusable for half the team. A customer portal that fails accessibility requirements without anyone realizing it until a complaint arrives.
We did not have a client watching over our shoulder on this one. We fixed it anyway, the same way we would fix yours. Thoroughly, verified, and without cutting corners once the visible problem was solved.
Technical Leadership
Leading Complex Builds Before Zapex
Not every proof of technical depth comes from a paying client. Before founding Zapex, Loretta led a five person team through a capstone project building the Manufacturing Performance Analytics Engine, or MPAE, a platform for turning raw shop floor data into real time operational insight.
This was an academic capstone, not client work. We are naming that plainly because we do not blur the line between the two anywhere on this site. What it does show is how Loretta approaches architecture and team leadership when the stakes are real, even without a paying client watching.
What It Does
MPAE ingests production, downtime, scrap, and shift data from the shop floor and calculates the core metrics manufacturing teams rely on: OEE, throughput, downtime, scrap rate, yield, and utilization, standardized across lines and shifts instead of pieced together in spreadsheets.
Architecture
- Eight microservices, including a dedicated Auth and Identity service, a Data Validation Engine, an isolated KPI Calculation Engine, and a Reporting and Export service, each with a single, clear responsibility.
- Role based access control enforced in two places by design. A frontend RoleGuard hides what a user should not see as a convenience, while a NestJS guard on the backend checks every protected route against the same permission map, so the UI can never be the only thing standing between a user and data they should not access.
- Deployed on Azure Kubernetes Service with ten Kubernetes resources, including autoscaling on the ingestion and KPI pods so batch imports do not slow the system down for everyone else using it.
- Azure Database for PostgreSQL for structured, time stamped operational data, and Azure Blob Storage for raw file staging and exported reports.
Key Decisions
- Separated the KPI Calculation Engine from ingestion and the dashboard, so heavy aggregation math never blocks a user loading their dashboard or slows down a data import in progress.
- Standardized the ingestion API payload format from the start, so the platform can move from capstone style CSV uploads to live shop floor connectors later without a rebuild.
- Aggregated data at the line, shift, and station level by default rather than the individual worker level, a deliberate choice to keep the platform focused on process improvement rather than surveillance.
Our Process
The Zapex Method
Every engagement follows the same four stages, from first call to production. Here is how it works, and what the Build stage actually produces.
01 Discovery Call
We learn your stack, goals, and constraints.
02 Proposal
Scope, timeline, and fixed pricing, no surprises.
03 Build
Rapid development with weekly check-ins.
04 Launch and Support
Deploy to production and iterate together.
What Build Actually Produces
Client requests
Dashboards and reports
Illustrative architecture. Not built for a specific client. Shown to demonstrate our approach.
Ready to find out what is hiding under your own systems?
Talk to us about your project
Get started