Work
Public code, project summaries, and representative delivery areas — enough to show the kind of problems I take on and how I approach them.
The catalogue
Showing 8 entries.
Commerce
Magento and Shopify storefront builds, custom extensions, checkout optimisation, integrations, search, security, and cloud operations.
Healthcare commerce
A commerce experience for selling and renting medical equipment, shaped around availability logic, payments, and real operational constraints.
ERP
Academic result and reporting system with role-based access for administrators, teachers, and students.
Real-time app
Live score applications built around frequently updating match data, with an interface that stays readable while it moves.
Lead generation
Responsive financial services site focused on trust, lead capture, and content management without unnecessary stack complexity.
ML / assistive UX
Emotion-detection experiment combining text or facial input analysis with suggested responses and interface adaptation.
Frontend lab
An interactive Fabric.js demo for placing and adjusting imagery inside SVG frames — the more exploratory side of frontend engineering.
Open repository ↗Frontend lab
A reusable Fabric.js text object that renders single-line text on a circular arc, built as an extendable component rather than a one-off demo.
Open repository ↗About this catalogue
Context for the entries above, and for the kind of engagement they came out of.
They are a cross-section rather than a full list. Commerce delivery on Magento 2 and Shopify sits at the centre; around it are ERP and role-based systems, real-time applications, lead-generation sites, and frontend experiments. Client work under NDA is not shown, so the public catalogue understates the volume of ecommerce delivery in particular.
For the frontend labs, yes — the Fabric Frame Demo and Text Curve Object repositories are public on GitHub and linked from their entries above. Client projects stay private, but I can walk through architecture decisions, data models, and trade-offs in a call, which is usually more useful than reading a diff.
Both, and existing stores are the larger share. Inherited Magento 2 and Shopify codebases, half-finished redesigns, stores that have slowed down or started failing patches, and migrations away from a platform that no longer fits — all normal starting points. A build does not need to be broken to be worth improving.
Four stretches, in order: understand the constraint the business actually runs on; build the spine — data model, key flows, and the interface that carries them; harden and tune for performance, technical SEO, access control, and patching; then hand over properly with documentation and editing setups a team can run. Skipping the first stretch is the usual reason a redesign gets rebuilt.
Yes. Diak Torad above is an academic reporting system with role-based access for administrators, teachers, and students; similar work covers inventory, approvals, status management, and ERP-style business logic for schools, healthcare, logistics, and inventory-heavy operations. Internal tools need the same clarity as anything customer-facing, and usually get less of it.
They are delivery requirements rather than separate engagements. Technical SEO — crawlability, structure, schema, internal linking, Core Web Vitals — and platform security — patching, hardening, access control, dependency hygiene — are built in during the work above, not quoted afterwards as remediation.
Have a similar challenge?