These case studies walk through real production systems I designed, built, or maintained for agency clients and in-house teams. They span secure authentication, payment automation, performance optimization, and operational tooling, built across ASP.NET Core, Laravel, Vue.js, React, and Node.js.
Each case study below covers the problem the client came in with, the architecture decisions that got it shipped, and what changed once it was live. I work across the full stack, from database schema and API design through to the frontend framework the client had already standardized on. So most of these case studies involve integrating cleanly with an existing codebase, rather than starting from a blank slate.
Table of Contents
What These Case Studies Have in Common
None of these projects started from a blank repository. Every one of these case studies begins with an existing system, an existing team, and an existing set of constraints — a client’s Azure AD tenant, a warranty provider’s billing calendar, a sportswear brand’s SKU catalogue, a safety-planning tool’s mobile release schedule, a brokerage’s spreadsheet-driven workflow. The engineering work in each case study is less about greenfield architecture and more about finding where a system is straining, and building the piece that removes that strain without breaking everything around it.
That constraint shapes how I approach every one of these case studies: understand the existing contract before changing it, keep the blast radius of any change small enough to reason about, and prefer boring, well-tested solutions over clever ones when something genuinely matters — payment activation, safety-critical mobile actions, identity and permissions. The five case studies below are a sample of that work across five different domains and five different technology stacks.
The domains are deliberately varied — optical retail, vehicle warranty and insurance, ecommerce customization, digital mental health, and real estate operations — because the underlying engineering problems repeat far more often than the industries do.
An identity layer that needs to serve multiple frontends, a payment flow that cannot tolerate a manual step, a pricing engine that needs to survive years of new SKUs, an API that has to fail loudly instead of silently, and a manual process that has outgrown spreadsheets: those five problems show up in some form across almost any production system, which is why these case studies are as much a reference for “how to think about this class of problem” as they are a portfolio of past work.
Specsavers: RESTful User Management and Secure Authentication
Building RESTful User Management APIs on ASP.NET Core with Azure AD authentication for a React front end, for Specsavers. The work centered on enterprise-grade identity: wiring up Azure AD as the authentication provider, designing role-based access control, and exposing a clean REST API for the React frontend team to consume without needing to understand the underlying auth complexity.
The Challenge
Specsavers needed a clean identity layer that could sit in front of a growing set of internal tools without asking every team to reimplement authentication from scratch. Azure AD (now Microsoft Entra ID) was already the organization’s identity provider, but exposing that safely to a React frontend team — without leaking token validation, claims mapping, or app-registration detail into every consuming application — was the actual problem. Frontend engineers wanted an API they could call, not a crash course in OpenID Connect.
The Approach
I wired Azure AD as the authentication provider at the API layer in ASP.NET Core, validating JWT bearer tokens against Azure AD’s OpenID Connect metadata, then layered role-based access control on top so every authorization decision lives in one place instead of being duplicated across endpoints. The REST endpoints were designed around the resources the React team actually needed — user profiles, permission sets, account status — rather than mirroring internal database tables, so the contract stays stable even as the identity plumbing underneath changes.
What Changed
The React frontend team can authenticate users and check permissions without touching Azure AD directly; they call the REST API and get a clean, predictable response. New internal tools built after this project can plug into the same identity layer instead of standing up their own authentication from zero, and role changes become a configuration change on the backend rather than a redeploy across multiple frontends.
WingWarranty: Payment Automation and UI Modernization
Reepay payment integration with automated subscription creation and activation, plus Vue.js UI work, for a vehicle warranty platform. The goal was to remove manual steps from the billing lifecycle — subscriptions now create and activate automatically on payment events — while the Vue.js frontend work brought the customer-facing UI up to date.
The Challenge
Warranty subscriptions were tied to a manual step somewhere in the billing lifecycle: a customer would pay, and someone — or some brittle script — had to notice and manually activate the subscription. That kind of manual gate does not scale, and it introduces both delay and error risk. A customer who has paid but whose coverage has not been activated is exactly the kind of gap that turns into a support ticket and a trust problem.
The Approach
I integrated Reepay’s payment API directly into the subscription lifecycle: webhook listeners for payment events that automatically create the subscription record and flip it to active status, with explicit handling for failure and retry states rather than assuming the happy path always occurs. Alongside the backend payment work, I refreshed the Vue.js UI to match the updated customer flows — checkout, plan summary, and coverage-status pages — so the frontend reflected the same real-time state the backend now guaranteed.
What Changed
Subscriptions activate the moment payment clears, with no manual gate in between. The support team no longer chases “why isn’t my warranty active” tickets tied to a slow manual step, and the modernized Vue.js interface gives customers clearer visibility into their coverage status at any point in the billing cycle.
Custimoo: Engineering a Sportswear Customization Platform
Fenerum and Stripe payment integrations, a SOLID-principles Pricelist module, DOM performance work, and Pantone-based dynamic SVG color mapping for a sportswear customization ecommerce platform. The color-mapping system lets customers preview accurate Pantone-matched colorways on customizable garments in real time, backed by a pricing engine built to stay maintainable as SKUs and rules grow.
The Challenge
The platform lets customers customize sportswear — colors, patterns, trims — and needed to preview garment colors that map accurately to the real Pantone reference codes manufacturing actually uses, live in the browser, without the page grinding to a halt every time someone hovers over a swatch. On the commercial side, pricing logic covering bulk discounts, per-SKU rules, and seasonal promotions had grown complicated, and needed both Fenerum billing and Stripe payments to plug into it without duplicating pricing logic in multiple places.
The Approach
I built dynamic SVG color mapping so garment previews recolor precisely against Pantone reference values instead of relying on approximate CSS filters, and did targeted DOM performance work to keep interactions smooth as the number of customizable parts scaled up. I designed the Pricelist module around SOLID principles specifically so new pricing rules could be added without touching the core pricing engine, then wired both Fenerum (billing and subscriptions) and Stripe (payments) against that single source of truth instead of letting pricing logic leak into either integration.
What Changed
Customers get an accurate, responsive preview of what they are actually buying, which cuts down on “the color wasn’t what I expected” support issues. The merchandising and pricing team can add new SKUs, discounts, and rules without engineering needing to touch the underlying pricing engine every time a new promotion goes live.
Minplan: Mobile App APIs for a Digital Safety Planning Tool
ASP.NET Core mobile app API work for a digital mental-health safety-planning tool, with an emphasis on reliability and testing rigor. Because the app supports people in vulnerable moments, the API layer was built with heavy test coverage and defensive error handling so the mobile client never silently fails on a critical action.
The Challenge
This app supports people during genuinely vulnerable moments. If the API silently fails, or returns an ambiguous error in the middle of a critical action — saving a safety-plan step, or reaching a support contact — that is not just a bug, it is a real-world risk. A standard “best effort” API reliability bar is not good enough when the client on the other end is a person who needs the app to work exactly when they need it most.
The Approach
I put heavy investment into unit and integration test coverage around every critical path, with explicit and defensive error handling so failure modes are visible and handled rather than silently swallowed. API responses were designed so the mobile client always knows, definitively, whether an action succeeded, needs a retry, or needs the user’s attention — no ambiguous or silent failure states anywhere in that path.
What Changed
The mobile client can trust the API’s responses. When something does fail, it fails loudly and recoverably instead of quietly, and that reliability bar became the standard the rest of the API surface was measured against as the product grew.
CityscapeOne: Building In-House Tools for a Real Estate Brokerage Platform
Mass mailing and Twilio mass messaging, user account and permissions management, and operational tooling built in-house at Cityscape Technology Corporation. These internal tools replaced manual, spreadsheet-driven processes with proper account permissions and bulk communication features the brokerage’s operations team now relies on daily.
The Challenge
The brokerage’s operations team ran a lot of day-to-day communication and account administration through manual, spreadsheet-driven processes: exporting lists, manually sending emails and texts, and tracking who had which account permission level by hand. That does not scale, and it is error-prone — the wrong list, the wrong permission level, no real audit trail when something goes wrong.
The Approach
I built internal tools directly to replace those manual steps: mass mailing and Twilio-based mass messaging so bulk communication happens through one system instead of ad-hoc exports, and a proper account and permissions management layer, so who-can-do-what lives in the application itself rather than in institutional memory.
What Changed
The operations team now runs bulk communication and permission management through tools built for the job, every day, instead of spreadsheets and manual sends — fewer errors, and a clear system of record for both communication history and account permissions.
Frequently Asked Questions About These Case Studies
What industries do these case studies cover?
These case studies span optical retail (Specsavers), vehicle warranty and insurance (WingWarranty), sportswear ecommerce (Custimoo), digital mental health (Minplan), and real estate operations (CityscapeOne). The industries are different on purpose — it shows the same engineering approach holding up across identity, payments, ecommerce, mobile reliability, and internal tooling rather than one narrow specialty.
Which technology stack shows up most across these case studies?
ASP.NET Core appears twice, in the Specsavers and Minplan case studies, both times as the backend for an API layer consumed by a separate frontend or mobile client. Vue.js appears in both the WingWarranty and Custimoo case studies as the customer-facing frontend. Across all five case studies, the constant is less a single framework and more a pattern: a REST API with a clear contract, sitting in front of whatever frontend or mobile client the client had already committed to.
Do you rebuild systems from scratch, or work inside what already exists?
Almost entirely the latter. Every one of these case studies involved an existing codebase, an existing identity provider, an existing payment processor, or an existing operations workflow. The engineering work was in designing the piece that plugs into that existing system cleanly — a REST API, a webhook-driven activation flow, a pricing module — rather than replacing what the client already had running in production.
How do you decide how much test coverage or reliability engineering a project needs?
By what is actually at stake if something fails silently. The Minplan case study is the clearest example: because the app supports people during vulnerable moments, the API layer got a much higher bar for test coverage and defensive error handling than a typical internal tool would need. Not every project needs that level of rigor, but knowing which ones do — and building to that bar deliberately, rather than by default or by accident — is part of the job.
How do you typically start an engagement like one of these case studies?
By understanding the existing system before proposing any change to it — what the current identity provider, payment processor, or workflow actually does today, who depends on it, and where it is genuinely straining versus merely imperfect. From there the work usually gets scoped as a concrete increment — a new API surface, a webhook-driven activation flow, a pricing module — rather than a full rewrite, since a full rewrite is rarely what a production system running real client traffic actually needs.
Why These Case Studies Matter
Read together, these case studies are less about any single technology and more about a consistent way of approaching production engineering work: identity and permissions that live in one place instead of being copied across every consuming app, payment logic that assumes failure will happen and handles it explicitly, pricing and business logic kept in a single module instead of duplicated across integrations, API reliability treated as a first-class requirement rather than an afterthought, and manual processes replaced with tooling the team actually uses every day.
None of that shows up as a flashy feature. It shows up months later, when the identity layer does not need to be rebuilt for the next internal tool, when a payment provider migration does not require touching five different services, or when a support team stops getting tickets about a problem that used to happen every week. That is the outcome these case studies are really about — fewer categories of problem the client has to think about after the project ships.
If you are evaluating a full-stack engineer for a project that looks like one of these case studies — an existing codebase that needs an identity layer, a payment integration that needs to stop depending on manual steps, or an operations team still running on spreadsheets — the underlying stack matters less than the approach. I work primarily in ASP.NET Core, Laravel, Vue.js, React, and Node.js, and I am always happy to talk through whether a project is a good fit before any commitment is made. You can see the kind of work this covers on the full-stack developer and Laravel SaaS development pages, or reach out directly through the contact page.
Most of these engagements start small — a scoped increment, a defined API surface, a specific integration — and grow from there once the working relationship proves out. That is a deliberate way of de-risking a new engagement on both sides: the client gets a concrete, reviewable piece of work before committing to anything larger, and I get to demonstrate the same standard shown across these case studies on their actual codebase rather than in the abstract. If one of these case studies looks close to a problem you are facing, that is usually a good sign the same approach will translate.
