Praxis Digital was my working practice for six years. I used it to build and support ecommerce sites, improve search and performance, and turn product-configuration work into a repeatable service.
I started Praxis in July 2019 and wound it down in October 2025. During that time I worked across more than 100 production sites, from focused fixes to longer storefront and product-configuration engagements.
The useful part was not the agency label. It was having one person who could follow a problem through product data, interface design, code, search visibility and ongoing support without losing the thread between hand-offs.
What I actually delivered
- Storefront development — WordPress and WooCommerce builds, custom integrations, reusable components and technical maintenance.
- Ecommerce operations — catalogue structure, checkout journeys, payments, B2B requirements and the systems staff used after an order or enquiry.
- Search and performance — crawlability, information architecture, Core Web Vitals, schema and content improvements implemented in the codebase.
- 3D product configuration — product rules, browser-ready assets, real-time rendering and integration with wider retail journeys.
- Support after launch — release planning, incident response, hosting coordination and a clear owner for routine changes.
Why the joined-up model worked
A product configurator is not just a 3D scene. Someone has to own the available options, prevent invalid combinations, make the controls understandable, and pass the finished result into a basket, quote or sales process.
The same is true of a conventional ecommerce site. Product data affects navigation. Theme decisions affect speed and search. Checkout changes affect fulfilment. Treating those as separate jobs usually creates gaps; treating them as one system makes the work easier to reason about and maintain.
Praxis worked best when I could trace a decision through the whole journey and give the client one clear explanation of what changed, why it changed and who owned it next.
Turning bespoke configurators into a repeatable platform
From 2021, product-configurator work became a distinct delivery line. I separated product state, asset delivery and the WebGL view so that a configuration could be validated, shared and passed into a wider commerce journey.
That architecture was used across more than 35 retail deployments. The important lesson was consistent: model the product rules first. A beautiful renderer cannot repair missing option data or an undefined order hand-off.
The separate product-visualisation research and WebGL case study explains the research background and the later platform in more detail.
How I ran the work
- Find the real owner. Record which system owns products, prices, stock, content and customer data.
- Start with awkward examples. Use representative products and known exceptions before scaling a pattern across a catalogue.
- Release in stages. Compare the candidate with the live environment, retain rollback and check the rendered result.
- Design for routine change. Give the next team a safe way to update the areas they actually own.
- Define measurements before quoting them. Record the metric, period, comparison and exclusions first.
What continued after Praxis
I closed Praxis operationally in October 2025. The broader web-development work continued through DreamWeb, while product configuration remained a specialist part of my own practice.
The method has stayed the same: establish ownership, prototype against real products, implement inside the real customer journey, verify the release and leave the next team with something they can operate.
A note on results
This page sticks to delivery scope I can support from retained records. I am not publishing old portfolio-wide conversion or revenue claims because I do not have a complete, permissioned evidence set that would make those numbers useful or fair to clients.
Planning a configurable-product project?
Start with the product rules, source assets and the system that needs to receive the finished configuration.