Zapex TechnologyGet started

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

Before and after metrics from the Zapex website rebuild
MetricBeforeAfter
WCAG accessibility errors (WAVE)210
Accessibility AIM Score5.5 / 1010 / 10
Lighthouse Accessibility—100 / 100
Lighthouse Best Practices—100 / 100
Lighthouse SEO—100 / 100
Desktop PerformanceFailed to measure94 / 100
Mobile Speed Index6.1s5.0s
Contact formSilently brokenFully 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.

  1. 01 Discovery Call

    We learn your stack, goals, and constraints.

  2. 02 Proposal

    Scope, timeline, and fixed pricing, no surprises.

  3. 03 Build

    Rapid development with weekly check-ins.

  4. 04 Launch and Support

    Deploy to production and iterate together.

What Build Actually Produces

Legacy system
API layer
Cloud platform
Faster outcomes

Client requests

API gateway
Microservices
Database

Dashboards and reports

Illustrative architecture. Not built for a specific client. Shown to demonstrate our approach.

Want the technical detail? Read our Engineering Standard

Ready to find out what is hiding under your own systems?

Talk to us about your project