Simba's Group Online Store

E-commerce Built on V-CMS 2.0

This implementation leverages all modern development standards using strongly-typed PHP 8.4+ (you can view more details about the platform's foundation here).

On the e-commerce side, and specifically for this project, the platform brings:

• Integrations with various third-party providers for shipping, card payments, and invoicing.
• A streamlined stock management system.
• Audit logging and tracking of administrator modifications.
• A comprehensive price history for products.
• A URL redirection system (301) for dead links.
• An in-dashboard notification system alongside traditional email notifications.
• A diverse reporting and analytics engine.
• Dynamic VAT management.
• A product documentation upload system utilizing a shared file repository.
• Fuzzy search capabilities across both the admin panel and the public storefront.
• Integration of the BCMath extension to eliminate classic floating-point rounding errors in PHP.
• Advanced security configurations: CSP policies and CSRF protection.
• Compliance with WCAG 2 A/AA accessibility standards.

Frontend Without React

While Single Page Application frameworks (like React) are highly popular in e-commerce, I believe this approach introduces an unjustified overhead for an online store. The practice of shipping megabytes of JavaScript just to render a functional website goes entirely against my performance principles. Therefore, for dynamic components, I chose a much lighter and highly efficient mix: HTMX and Alpine.js.

Development Workflow

The development environment implements Unit Tests, PHPStan, CS Fixer, and Playwright. The entire workspace is fully containerized using Docker.

My Favorite Feature

The homepage slider is unique: it can dynamically pull product data, supports custom image uploads, or lets you choose directly from the product's image gallery. Most interestingly, its background and accent colors are automatically adapted by extracting the dominant shades from the selected image.

While every other subsystem and feature in the application required hard engineering and was beautiful in its complexity, this slider was a passion project. It was designed specifically because the store operator lacks a dedicated marketing team, and slider layouts can easily become an aesthetic mess. This automation ensures a consistent, clean, and visually pleasing design, no matter what image is selected.

Results after launch

First of all, these screenshots, not many people see these results in a live application: 100 points across all tests on desktop.

Unfortunately on mobile, after all the tracking tags have been configured we have these numbers: 67 on average on performance and 100 points on the rest of the tests.

It is nevertheless a very high standard, and in operation, it feels smooth. Amusingly, the tags occupy about 60% more of the main thread than all the JS in the application combined. Looking at the bright side, all this main thread usage isn't useless. Event and conversion tracking is set up impeccably. Everything is delivered through Google Tag Manager, and settings can be exported and imported, ensuring smoothness and ease in new deployments.

As a side note, post-launch traffic increased by approximately 25% while maintaining the exact same marketing spend.

Another impressive win is that organic indexing was not affected. With a few well-placed 301 redirects and a build that respects legacy structure, the transition was seamless.

Post-Launch Issues

Initially, I made a mistake. The checkout and account system were optimized for recurring orders, which isn't the case for this specific project. In this product niche, users place orders that are fairly high in average order value, but the reorder rate is low. That meant a checkout redesign after the first week.

The checkout now supports guest users, and the required fields to complete an order are kept to an absolute minimum.

For users who still opt to create an account, subsequent orders can be placed with 1-click based on saved details. So we hit a sweet spot between convenience for new and returning customers.

Another issue I didn't anticipate was related to INP (Interaction to Next Paint). In hindsight, it makes sense given how Alpine and HTMX operate by default. HTMX components, such as modals, render only after the server request completes. Under normal conditions everything feels snappy, but on weak networks or legacy devices, there can be a noticeable delay between clicking a button and seeing an action. As a fix, almost all storefront buttons now feature loading and disabled states. This ensures immediate UI feedback regardless of network conditions.

Another interesting result is bandwidth consumption. For 10,000 unique visitors and 100,000 page views, the server reports a nearly 50% reduction in bandwidth. It wasn't explicitly a target, but it seems to be a natural byproduct of an optimized application.

In conclusion, the system looks very promising. The primary goals: performance, accessibility, SEO, smoothness, and ease of operation for both admins and customers have been met. Spam has been significantly reduced using request throttling and automated IP bans. Google Analytics and AdWords now rely on real conversion data, which is gradually leading to far better optimized campaigns based on actual metrics.

Going forward, the application is being actively monitored via an Audit Log system to catch and resolve any operational issues or anomalies as soon as they appear.