WordPress plugin developer
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. 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 · working with businesses across Kentucky and Southern Indiana
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, enquiries, 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, cancelled - 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 catalogue sync
Reconciles the till’s catalogue 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 centre 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
In development- Listing-linked enquiriesBuyer 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 · in development
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. Enquiries 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 enquiries as their own record type, and a deposit-and-commission model that keeps the platform’s cut out of anything the buyer sees. Not launched yet - a live development build, shown because it is the clearest example on the page of code doing what a catalogue cannot.
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 cancelled, every transition dated. It lives inside Mission Control, a branded desk workspace on a restricted role that reaches orders, enquiries, 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 colour.
Two things most stores get wrong. Advertising scripts that fire before the visitor has agreed to anything. And a colour 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 colour, 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 enquiry 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 licence 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.
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 we 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. Productised versions: POS integration, online booking, guest check-in and digital guest books.
All screenshots on this page were captured in development environments using synthetic records created for the purpose and removed afterwards. Peerless limits shown are the values observed in its development environment. HogMatch is a development build and is not launched; no live sale, payout or commercial result is claimed anywhere on this page.