A WordPress plugin developer in Louisville, for rules no plugin ships with.
Every WordPress site eventually needs something the plugin directory does not sell. Usually it is not a feature - it is a rule. Staff may do this, customers may not. This animal is one of one. Rules like that live in code, and somebody has to write them. I am available for hire as a freelance WordPress plugin developer, from Louisville, for businesses anywhere in the United States. This page is about the developer and the work; the custom plugin development service page covers what a build includes and how it is priced.
Louisville, Kentucky · for hire across Kentucky, Southern Indiana and the United States
Or call or text (502) 387-1142
ship-rules
class-ship-rules.php
rest-api.php
admin-table.php
data
states.json
tests
1<?php
2namespace ShipRules;
3
4/**
5 * Decide at checkout whether an order may ship to this address.
6 * The rules live in one table the owner can edit, not in code.
7 */
8final class Rules {
9 public function allowed( $cart, $address ) {
10 $rule = $this->for_state( $address['state'] );
11 if ( ! $rule || 'blocked' === $rule['status'] ) {
12 return new \WP_Error( 'ship_blocked', $rule['message'] );
13 }
14 if ( $this->bottles( $cart ) > $rule['max_bottles'] ) {
15 return new \WP_Error( 'ship_limit', 'Over the state limit.' );
16 }
17 return true;
18 }
19}
20
21add_action( 'rest_api_init', function () {
22 register_rest_route( 'ship-rules/v1', '/check', array(
23 'methods' => 'POST',
24 'callback' => array( new Rules(), 'rest_check' ),
25 'permission_callback' => '__return_true',
26 ) );
27} );
$ wp scaffold plugin-tests ship-rules
Success: Created test files.
$ wp ship-rules check --state=KY --bottles=6
allowed rule: ships, max 9 bottles
$ wp ship-rules check --state=UT --bottles=1
blocked rule: no direct shipping to Utah
$ wp ship-rules check --state=TX --bottles=12
limit rule: max 9 bottles per order
$ wp ship-rules import data/states.json
Success: 50 states and DC imported, 0 errors.
$ vendor/bin/phpunit
OK (92 tests, 401 assertions)
$ curl -s -X POST /wp-json/ship-rules/v1/check -d '{"state":"OH"}'
{"allowed":true,"max_bottles":9}
> Checkout blocks the address before payment, not after
Dashboard
Orders
Products
Ship Rules
Customers
Settings
Built, not bought
The work I would lead with
Five systems that could not have been bought. Each one replaces something a business was otherwise paying for monthly, doing by hand, or doing wrong.
Mission Control
A branded front-desk workspace that pulls orders, inquiries, gift certificates and flight scheduling onto one screen - running on a custom role that can reach exactly those things and nothing else.
The alternative is handing desk staff a WordPress administrator account so they can process a booking. Most agencies do exactly that.
The flight fulfilment ledger
A paid order and a flown flight are not the same event. Payment completes normally while a separate queue tracks the aircraft: needs scheduling, contacted, scheduled, weather hold, flown, canceled - each transition dated.
WooCommerce has no concept of weather. An aviation business that cannot record why a paid flight has not happened yet is running on a spreadsheet.
Point-of-sale catalog sync
Reconciles the till’s catalog against the website by SKU and Product Code as separate fields, with an explicit rule about which system owns the count, and a comparison view showing the exact before-and-after quantity of every planned change. Where two products share a code, it raises the conflict instead of guessing.
Commercial POS connectors are sold on monthly subscription and priced on order volume, so the bill grows as business improves. This one is owned outright and shaped around one distillery’s rules.
Named-experience gifting
Buy a specific flight for a specific person. Recipient details and a scheduled delivery date, a generated certificate rendered identically for email, web and print, redemption restricted to the experience actually purchased, and a desk control to mark it flown - or undo that if it was pressed by mistake.
Gift-card plugins move money. None of them know that this certificate is for a discovery flight and cannot be spent on merchandise.
Marketplace deposit and commission ledger
One animal, one unit, and money that has to split. Custom code separates the seller’s listing fee from the animal’s price, calculates a deposit, allocates the platform’s commission against it, derives the breeder’s portion and leaves a pickup balance - while keeping the commission out of anything the buyer ever sees.
A normal checkout has one buyer and one seller. A marketplace has three parties and two payments, and no product checkout expresses that on its own.
Plugin, or code?
What “custom” actually means
Not a theme tweak, and not a plugin with the settings turned up. Four things separate real plugin work from configuration.
Permission, not appearance
Hiding a field with CSS is decoration - anyone can undo it in ten seconds. A real permission is a named capability like peerless_book_override that the server checks before it does anything, granted to specific people and no one else.
Enforced on the server
Every rule is checked again on the way in, after the browser has had its say. If the check only happens in JavaScript, it is a suggestion, not a rule.
Your data outlives the tool
Records get their own storage rather than borrowing a field from somebody else’s plugin - an independent ledger, a dedicated record type. When a plugin is replaced, the history stays.
Separate from the design
Business logic lives in a plugin, not in the theme. Redesign the site in three years and the rules keep working, because they were never tangled up in how it looked.
Everything else
And the rest of it, briefly
Beyond the five above and the case studies. Every one of these is code running on a real site, written because the installed plugins did not do that particular thing.
Kentucky Peerless Distilling
In production- Public guest-book kioskA tablet in the visitor center collecting newsletter signups. Every signup is written to its own database first and synced to the mailing list second, with a local queue if the wi-fi drops and a stored record of exactly what each person consented to. A newsletter provider having a bad morning should not cost you a consented signup.
- Point-of-sale inventory reconciliationCovered in full above. Running in production, pulling till quantities into the website hourly.
Cardinal Wings Aviation
In development- Sales tax fallbackWhere a taxable shipping address is missing its state, tax is calculated from the billing address before payment is captured, and the order is flagged for incomplete fulfilment information rather than silently corrected. Vendome Copper.
- Legacy certificate continuityCertificates sold under the previous system keep working, with their original codes, alongside the new store’s balances.
- Review hub and content approvalsPer-page client review notes with threaded replies, plus separate approval queues for media and posts with revision history and re-approval when content changes.
HogMatch
Live- Listing-linked inquiriesBuyer questions attach to the animal, not a general inbox. Before a deposit, the seller sees a generated handle rather than the buyer’s contact details.
- Marketplace operations dashboardSeller approval queues, configuration and health checks on their own permissions, separate from site administration.
- Video processingSellers upload video of an animal moving; the upload is ticketed to a streaming provider and its processing state stays tied to the listing.
- Transactional mail relayMarketplace notifications routed through a delivery provider when ordinary site mail is not dependable enough.
Some of these are one file. Some are a dozen working together. What they have in common is that each one exists because the installed plugins did not do that particular thing, for that particular business.
Custom work, up close
Six systems, and what they changed.
A livestock marketplace, a distillery, an aviation business, my own store, a copper fabricator and a 3D print shop - opened up screen by screen, so you can judge the work rather than take my word for it.
HogMatch / custom marketplace · live
A marketplace where one pig is a proper listing.
Show-pig breeders sell one animal at a time, and the big auction sites price for volume, so smaller breeders end up selling through Facebook groups. A store sells products; a marketplace is a different species of thing. Sellers apply and get approved. Each listing has exactly one unit that must never oversell. Buyers filter on breed, sex and location. Inquiries belong to the animal, not a general inbox. And money splits three ways.
WooCommerce stays as the commerce foundation. On top of it, a plugin adds the animal record, an approval workflow gated by hogmatch_list_pigs, a seller dashboard scoped to what they actually own, listing-linked inquiries as their own record type, a video pipeline that takes the clip a breeder films on a phone, processes it and plays it on the listing, and a deposit-and-commission model that keeps the platform’s cut out of anything the buyer sees. Live at hogmatch.com since September 2026, taking deposits at checkout, and the clearest example on this page of code doing what a catalog cannot. Read the HogMatch case study.
Kentucky Peerless / point of sale · in production
A till and a website that finally agree.
A distillery sells the same bottle from a tasting-room till and from a website. When those two disagree about how many are left, somebody either oversells a bottle that is not there or refuses a sale for one sitting on the shelf. Commercial sync platforms were tried over several years. The inexpensive tier did not hold up. The tier that covered the real operation was priced on order volume - and one vendor counted orders from both connected systems toward the allowance, even though only inventory sync was wanted.
So: a reconciliation workflow shaped around this distillery’s rules. It matches on SKU and Product Code as separate fields, because they are. It has an explicit stock-authority setting. Where two products collide on a code, it surfaces the conflict instead of picking one. And a comparison view shows exactly what would change, item by item, before it is applied. Honestly: scheduled quantity pulling runs on its own and does not stop for approval; outbound write-back of online sales is built and currently switched off.
Cardinal Wings Aviation / front desk software · in development
Paid is not the same as flown.
Somebody buys a discovery flight online. The payment succeeds immediately. The flight happens weeks later, if the weather allows. Standard ecommerce treats those as one event and marks the order complete the moment the money clears - which tells the front desk nothing about who is still waiting to fly. And the staff working that queue should not be handed a WordPress administrator account to do it.
A separate fulfilment ledger runs alongside the order: needs scheduling, contacted, scheduled, weather hold, flown or canceled, every transition dated. It lives inside Mission Control, a branded desk workspace on a restricted role that reaches orders, inquiries, certificates and scheduling and nothing else on the site. Alongside it, named-experience gifting: a flight bought for a specific person, a certificate rendered identically for email, web and print, redemption limited to the experience purchased, and a desk control to mark it flown.
Island Earth / my own store · in production
Consent first. Then the photograph follows the color.
Two things most stores get wrong. Advertising scripts that fire before the visitor has agreed to anything. And a color picker that changes the word beside the swatch but not the photograph, so the shopper never actually sees the thing they are buying.
A consent gate holds the tracking and attribution scripts inert until somebody actually accepts - verified by watching the script tags themselves change state at the moment of consent, not by trusting a plugin’s word for it. The product experience swaps the imagery when you choose a color, keeps the real WooCommerce variation controls intact underneath, and a purchase bar follows you down the page. Underneath, a shipping rate filter fixed free-shipping thresholds that were silently never applying. It is my own store, which is why it can be opened up completely.
Vendome Copper & Brass Works / shop-floor tool · in production
Shop-floor maths, in sixteenths.
Copper stills are circles. People on the shop floor and customers planning a build keep needing the same conversions - circumference to diameter, arc length around a curve, the straight chord across it - and keep phoning to ask. Generic calculators answer in decimals. A fabrication shop works in feet, inches and sixteenths. A tool that says 38.197 inches has not answered the question.
A standalone calculator that takes decimal inches or feet-inches-fractions, returns fractional output at a precision you choose, and draws the circle with the entered angles marked so the numbers are checkable at a glance. Runs entirely in the browser, on a phone, in a fabrication bay with two bars of signal. It deliberately sits outside WordPress - which is why a WordPress-only server migration skipped it this year and it had to be restored. Knowing which parts of a site are not WordPress is part of the job.
Cru Bear 3D Printing / my own business · in production
A form that actually opens the file.
People asking for a 3D print need to send the actual model. Those files are containers - an STL, a STEP, a 3MF holding a whole folder structure inside it. A normal contact form either refuses them outright or accepts something broken, and nobody finds out until the print fails. Form plugins check the extension and the size. That is not validation.
An extension to the inquiry form that understands model and CAD formats properly. It opens a 3MF and checks the nested paths and internal assets are genuinely there, and it stopped rejecting legitimate files that merely looked over-compressed. A real part is accepted; a broken upload is caught at the door instead of three days later.
The honest answer
When it is worth writing code
Custom development is the expensive answer. It is the right one less often than developers like to admit.
Write the code
- The rule is different for different people, and it has to hold when someone tries to get round it.
- Two systems need to agree - a till, a booking calendar, a fulfilment partner - and nobody wants to retype anything.
- Staff are keeping a spreadsheet alongside the website because the website will not do the thing.
- You are paying monthly for four plugins to half-cover one workflow.
- The data has to outlive whatever plugin is holding it today.
Buy the plugin
- Something reputable already does it and is actively maintained.
- It is a look rather than a rule.
- It is genuinely once a year and a person can just do it by hand.
- The requirement is still moving. Custom code sets a decision in place; make the decision first.
- Nobody at your end will own it after handoff.
From rule to release
How the work runs
Nothing gets written until the rules are written down and agreed, and nothing touches your live site until it has run somewhere else first.
Watch the actual job
What staff currently do, including the workarounds. The workarounds are usually the specification.
Write the rules down
Who may do what, under which conditions, and what must never happen. In plain English, agreed before any code exists.
Build on a copy
A development clone of your site. Real structure, no real customers, nothing at risk.
Deploy and hand over
Onto the live site with a backup taken first, plus commented code and written notes for whoever comes after me.
Before you commit
Questions people ask first
Do I own the code?
Yes. It is your plugin, sitting in your site’s files, on your hosting. No license key, no monthly fee to me, nothing that stops working if you stop working with me. You can hand it to another developer tomorrow - it is written to be readable by one.
Will it break when WordPress updates?
Custom code written against WordPress’s documented interfaces - capabilities, hooks, filters - is generally more stable than a marketplace plugin, because those interfaces change slowly and deliberately. The real risk is a plugin it integrates with changing underneath it. That is worth a maintenance arrangement; it is not worth avoiding custom code over.
What does it cost?
It depends entirely on how many rules there are and how many systems have to agree. A single well-defined rule - one permission, one screen - is a small piece of work. A marketplace with approvals, payments and a seller dashboard is a project measured in months. I quote from a written specification, not from a conversation, so you are never approving a number attached to a vague idea.
Can you fix a custom plugin somebody else wrote?
Often, yes - that is a large share of the work that comes in. Half-finished builds, a developer who went quiet, a site where nobody knows what a file does any more. The first step is reading it and telling you honestly whether it is worth repairing or worth replacing.
Why are these screenshots all test data?
Because they are pictures of other people’s businesses. Every screen here was captured on a development site using invented names, invented animals and invented numbers, and every image was checked before it went up. No client’s customer, guest or transaction appears anywhere on this page. Yours would get the same treatment.
Can I hire you for one feature, or only for big projects?
Either. A single rule, one screen or a fix to someone else’s plugin is a normal week here, and it is how most longer relationships start. Bring the problem, not a specification; writing the specification is part of the work.
Describe the rule you cannot make WordPress follow.
If it can be done with a plugin you already own, I will tell you that and you will have lost nothing but an email. If it cannot, you will get a written specification and a real number before anybody commits to anything.
Start the conversationLouisville, Kentucky · usually a same-day reply
Related
The plugin is one piece. Here is the rest.
These tools sit inside sites I also design: web design in Louisville, e-commerce website design on WooCommerce, and manufacturing websites where a quote calculator was the custom piece. The overview of every plugin is on custom WordPress plugins, the person writing them is a Louisville WordPress developer, and once a plugin ships it is kept current under WordPress maintenance. Productized versions: POS integration, online booking, guest check-in and digital guest books. I also publish a free one, Mail Auth Check, a WordPress email authentication plugin.
Screenshots on this page come from test copies of each system with sample records, so no customer’s details appear. HogMatch has been live at hogmatch.com since September 2026. Cardinal Wings’ front desk software is still in development.