A premium meat shop stopped losing orders. After 6 weeks: zero double-sold cuts, zero failed redirects, zero manual refunds.

A store losing customers

What that chaos really cost.

"The site is slow" is abstract. Concrete costs are team hours and lost orders at peak.

30 minute audit

Three of these numbers explained everything the client reported:

• 40 MB of PHP memory — even though the host declared 512M in php.ini. The limit was hardcoded in wp-config.php by a previous developer. Any heavier query (export, report, composite product) ate the free memory and came back as a 500.
• No object cache — every product page ran 200+ MySQL queries on every visit. With 46 plugins, that meant hundreds of milliseconds of database time per click.
• No native stock locking — out-of-the-box WooCommerce lets two customers add the same cut to their cart simultaneously. That's not a bug, it's a feature. For a store with unique products, it's a disaster.

How the store lives now. After 6 weeks.

It was not about being "faster" - it was about the client team not having to call their customers to apologize.

The most important change isn't measurable in seconds or gigabytes of memory. It's the change in how many hours per week the Royal Beef team spends on the store instead of on customers, meat and the farm.

Here we describe how. There you see what it looks like.

A case study is the view from the kitchen — technical decisions, trade-offs, code that carries atomic stock locking. The portfolio entry is the same project from the customer's side: what the Royal Beef shop looks like, the colours, the product photography, the cart that finally doesn't lose items.

Numbers the client sees. And what they mean for business.

All measurements from production - PageSpeed Insights with CrUX field data (28-day rolling), wp-cli for PHP memory, server logs for protocols. No lab tests.

Do you recognize your store in this story?

Most Polish WooCommerce stores with 500K-5M PLN annual turnover have a similar setup. If any of these questions sound familiar - you probably have the same conversation ahead.

For developers: stack, decisions, code.

12 elements of the production stack, 8 architectural decisions with rationale, 3 code blocks from the rb-cart-reservation plugin, request flow diagram.

function rb_reserve_stock($product_id, $qty, $session_id) {
    global $wpdb;

    $table = rb_stock_table();      // HPOS vs postmeta
    $ttl   = 900;                  // 15 min hold

    $wpdb->query('START TRANSACTION');

    // row-level lock — the second process waits
    $row = $wpdb->get_row( $wpdb->prepare(
        "SELECT stock, reserved FROM {$table}
         WHERE product_id = %d FOR UPDATE",
        $product_id
    ));

    $available = $row->stock - $row->reserved;

    if ($available < $qty) {
        $wpdb->query('ROLLBACK');
        return new WP_Error('rb_no_stock', __('Out of stock', 'rb'));
    }

    $wpdb->query( $wpdb->prepare(
        "INSERT INTO rb_stock_reservation
         (product_id, qty, session_id, expires_at)
         VALUES (%d, %d, %s, NOW() + INTERVAL %d SECOND)",
        $product_id, $qty, $session_id, $ttl
    ));

    $wpdb->query('COMMIT');

    return true;
}

function rb_stock_table(): string {
    global $wpdb;

    // HPOS enabled? Check the WooCommerce feature flag
    if (class_exists( '\\Automattic\\WooCommerce\\Utilities\\OrderUtil' )
        && \\Automattic\\WooCommerce\\Utilities\\OrderUtil::custom_orders_table_usage_is_enabled()) {

        return "{$wpdb->prefix}wc_orders";
    }

    // fallback: classic postmeta
    return "{$wpdb->prefix}postmeta";
}

add_action('rb_cleanup_reservations', function () {
    global $wpdb;

    $wpdb->query(
        "DELETE FROM rb_stock_reservation
         WHERE expires_at < NOW()
         LIMIT 200"      // batch — don't block the request
    );
});

// schedule every minute
if (! wp_next_scheduled('rb_cleanup_reservations')) {
    wp_schedule_event( time(), 'rb_every_minute', 'rb_cleanup_reservations' );
}

Frequently asked questions.