Shipping Code is Better Than Perfect Code

I recently took over a WooCommerce project for a client whose last developer had vanished. The site was old, cluttered with plugins, and the checkout process was a mess. The client had a simple request: add a custom “Delivery Instructions” field to the checkout and save it to the order. Should be simple. An hour, maybe two. Right?

Famous last words. When I dug into their functions.php, it was a total nightmare. A tangled web of hooks, deprecated filters, and anonymous functions with no comments. My gut reaction, the craftsman in me, was to tell the client we needed to burn it all down and refactor the entire checkout. I started mapping it out—a full-blown project to modernize the code, implement a proper class structure, the works. It was beautiful in my head. And it would have taken a week.

But the client didn’t need a masterpiece of modern architecture. They needed a text box. This is the classic developer trap, something I’ve seen junior devs fall into and, if I’m honest, a trap I still have to stop myself from falling into after 14 years. It’s the “love of creation,” as Jason Cohen once put it in a post I still think about, which I found via an old article on carlalexander.ca. We love to build clean, perfect things. But perfect is often the enemy of shipped.

Pragmatic PHP Development: Sidestepping the Refactor Trap

The client’s budget was for a few hours, not a full week. Pitching a massive refactor wasn’t just overkill; it was tone-deaf. It didn’t solve their immediate problem and would have tanked their budget. The pragmatic solution isn’t always the most elegant one, but it’s the one that respects the client’s reality.

So, I threw out my grand refactoring plan. Instead of trying to fix everything, I focused on finding the single, correct point of entry. I needed one hook to add the field and another to save the data. That’s it. No rewriting their entire checkout flow. I just needed to inject my little piece of functionality with surgical precision.

After a bit of digging, the right hooks turned out to be woocommerce_after_order_notes to display the field and woocommerce_checkout_create_order to save the data. Here’s the kicker: the code isn’t revolutionary, but it’s clean, isolated, and it works without disturbing the hornet’s nest of legacy code around it.

/**
 * Add the custom field to the checkout page.
 */
add_action( 'woocommerce_after_order_notes', 'bbioon_add_delivery_instructions_field' );
function bbioon_add_delivery_instructions_field( $checkout ) {
    woocommerce_form_field( 'delivery_instructions', array(
        'type'          => 'textarea',
        'class'         => array('form-row-wide'),
        'label'         => __('Delivery Instructions'),
        'placeholder'   => __('Special instructions for the delivery driver.'),
    ), $checkout->get_value( 'delivery_instructions' ));
}

/**
 * Save the custom field to the order meta.
 */
add_action( 'woocommerce_checkout_create_order', 'bbioon_save_delivery_instructions_field', 10, 2 );
function bbioon_save_delivery_instructions_field( $order, $data ) {
    if ( ! empty( $data['delivery_instructions'] ) ) {
        $order->update_meta_data( '_delivery_instructions', sanitize_textarea_field( $data['delivery_instructions'] ) );
    }
}

So, What’s the Point?

The real fix here wasn’t the code. It was the mindset. It’s about recognizing the difference between what is *possible* and what is *necessary*. We’re paid to solve business problems, not to build our personal software cathedrals.

  • Identify the actual need: The client needed a text field, not a new checkout system.
  • Find the path of least resistance: Work *with* the system, even if it’s messy. Find the right hook or filter to get the job done without breaking everything else.
  • Ship the solution: A working feature delivered on time is infinitely better than a “perfect” refactor that never gets finished.

Look, this stuff gets complicated fast. If you’re tired of debugging someone else’s mess and just want your site to work, drop my team a line. We’ve probably seen it before.

Could that checkout still use a refactor? Absolutely. And I’ve made a note to recommend it to the client for a future phase. But for now? We solved the problem. We shipped. And that’s the win.

author avatar
Ahmad Wael
I'm a WordPress and WooCommerce developer with 15+ years of experience building custom e-commerce solutions and plugins. I specialize in PHP development, following WordPress coding standards to deliver clean, maintainable code. Currently, I'm exploring AI and e-commerce by building multi-agent systems and SaaS products that integrate technologies like Google Gemini API with WordPress platforms, approaching every project with a commitment to performance, security, and exceptional user experience.

Leave a Reply

Your email address will not be published. Required fields are marked *