Cap Ezi-Parts Platform Rebuild
Ground-up rebuild of Capricorn's parts sourcing platform, migrating from Laravel/Vue on AWS to React/.NET on Azure — cutting load times from minutes to seconds and reducing infrastructure costs by over 95%.
Overview
Cap Ezi-Parts is a parts sourcing platform used by Capricorn members across Australia and New Zealand. It lets automotive workshops search for parts across a network of preferred suppliers, request quotes, and manage orders — all from a single interface instead of calling around or checking multiple catalogues.
I initially came onto the project to support the existing v1 application, built on Laravel and Vue. Over a year of hands-on support and bug fixing gave me deep familiarity with the codebase and its pain points. When the decision was made to rebuild from the ground up, I was well placed to help shape what v2 would look like.
The Problem
The v1 platform had significant performance issues. Key workflows — searching for parts, loading quotes, navigating between views — could take minutes rather than seconds. For members who rely on speed to keep their workshop running, this was a dealbreaker. Some had already started moving to competing platforms.
Infrastructure costs were also a concern. The AWS-hosted RDS instance alone was costing $4,000–6,000 AUD per month, which was difficult to justify given the experience it was delivering.
Technical Approach
The rebuild moved the entire stack from Laravel/Vue on AWS to a React frontend with a .NET backend hosted on Azure. I was the primary contributor to the frontend across both mobile and desktop, and played a key role in the architecture decisions around the cloud migration.
Performance-First Frontend
The biggest user-facing wins came from rethinking how the app fetched and managed data. Rather than waiting for full page loads, we implemented aggressive prefetching — anticipating what data a user would need next and loading it in the background before they navigated.
React Query became central to the data layer. We used its mutation and cache invalidation patterns to keep the UI responsive during write operations, updating the interface optimistically while syncing with the server in the background. For search-heavy flows, this meant results appeared near-instantly even on slower connections.
Cloud Migration
Migrating from AWS to Azure involved rearchitecting the deployment pipeline, database layer, and hosting infrastructure. A key outcome was reducing the database costs from the $4,000–6,000/month RDS instance down to a couple of hundred dollars — a reduction of over 95% — without sacrificing performance.
Mobile & Desktop
The v1 app had been desktop-first, with mobile as an afterthought. For v2 we designed mobile and desktop experiences in parallel, making sure the workflows that matter most in a workshop environment — quick part searches, quote comparisons, order tracking — worked well on a phone screen.
Challenges
Earning trust through support. The year I spent supporting v1 wasn’t just maintenance — it was relationship building. Understanding the client’s frustrations firsthand meant I could advocate for the right technical decisions during the rebuild. That trust directly led to the client engaging us for further work beyond the initial project scope.
Balancing speed and correctness. Optimistic updates make the UI feel fast, but they introduce complexity around error handling and rollback. We invested time in building robust patterns for handling mutation failures gracefully, ensuring the UI never showed stale or incorrect data for more than a brief moment.
Results
- Load times for key workflows reduced from minutes to seconds
- Infrastructure costs cut from $4,000–6,000/month to ~$200/month (95%+ reduction)
- Fully responsive experience across mobile and desktop
- Client relationship maintained and strengthened, leading to ongoing engagement
- Members who had been considering alternative platforms retained on the new version