Backend engineer. Laravel at home, curious everywhere else.

The problem. A catalogue arrived as CSVs on an FTP server and had to become Shopify products, variants and collections, then be retired on schedule.

What I built. An hourly pipeline that processes files deterministically by modification time, isolates failed rows and re-uploads them for retry, and cleans up what succeeded. It uses GraphQL bulk mutations, paces image uploads by the API's reported cost, stores Shopify IDs locally to skip redundant calls, creates rule-based collections on first use, and handles drop dates through scheduled jobs. A full mutual-exclusion lock means only one import or deletion runs at a time.

Result. Handles ~32,000 variants in production. I was the sole developer.

The problem. Two production apps talking over APIs: one on Laravel 5, one on 9, with years of data debt and a permission model that no longer matched the client's needs.

What I did. Led the upgrades to Laravel 12, the schema changes and legacy-data cleanup, all proven on staging first. I redesigned access around a company-level hierarchy with fine-grained permissions. One requirement shaped the design: roles are permission templates, so editing a role never silently changes the access of people already assigned to it.

Result. Both apps run on Laravel 12 with their functionality and API link intact, and a far easier base to extend. Removed data was only what the client asked to have cleaned up.

The problem. More than a product catalogue: admin-configurable product data, approval-based onboarding, fine-grained access control, ordering, notifications, and constant sync with the client's in-house Oracle system.

What I built. The API and domain model, including properties admins can define as filters, sliders or info fields without a developer. Sign-up works with email, Google or Apple, with admin approval before access. Auth runs on Sanctum and Fortify, with RBAC covering both the CMS and individual API actions. Notification templates are CMS-managed, rendered with Mustache and sent via queues. I also configured the production Linux server and later migrated the app to a replacement.

Result. Live, in public use, and still evolving without needing a new architecture.

The problem. Track stock, cost and pricing for a manufacturing client, and keep the books honest as requirements kept growing.

What I built. A voucher-based model for movement and accounting (purchases, receipts, deliveries, adjustments), with warehouse bins, factory allocation, stock transfers and reconciliation. It evolved heavily as the client's needs expanded.

Servers too. I set up and ran the in-house Linux server: Apache, MariaDB, access controls, firewall rules and automated security updates.

The server. Upgraded Ubuntu 16 LTS to 24 LTS and moved PHP to the newest version the app supports. Infrastructure only, by client choice, which kept things stable and extended the server's life.

The app. Replaced hard-coded, enum-like types with a normalised, CRUD-managed model, changing schema, admin workflows and API responses without breaking existing consumers. Added hierarchical roles (chief-level roles managing agencies in scope) with access control enforced in the backend, and extended the domain models for new business workflows.

The outage. A production failure traced to a deprecated S3 integration. I upgraded the obsolete AWS SDK to v3, which stabilised asset handling in a codebase untouched by updates for years.

Pace. Phase one, the enum-to-CRUD refactor, shipped in under a week.