A customer asks whether they can book online. Or you decide that quotes should stop living in your inbox. Or the bookkeeper wants the website to talk to the system that already holds the invoices.
The instinct is to ask whether the site can do it, and that is the question that leads to a rebuild. The useful one is which of four forms the feature should arrive in, because only one of those forms is custom software and the other three are usually faster, cheaper, and much easier to walk away from.
Four ways a feature can arrive#
Every request lands in one of these. Working out which one before you ask anybody for a price is most of the work.
| Route | What it is | What it really costs |
|---|---|---|
| An existing plugin | Somebody built it already and you configure it | Small money, plus your time learning whose workflow it assumes |
| A hosted service you embed | The feature runs on another company's product and appears on your page | A monthly fee, your data living there, and their styling |
| An API connection | Your site talks to a system you already pay for | A developer once, then almost nothing, until the other side changes |
| Custom code | Built around how you actually work | The most, and it is the right answer when the requirements are yours |
Try them in that order. Not because the first is cheapest, though it usually is, but because the price of choosing wrongly grows as you go down the list. A plugin you regret is uninstalled in a minute. Custom code you regret is yours to maintain for as long as the site lives.
Describe the feature out loud without naming your company or anything specific to it. If the description survives that, somebody has already built it and your job is to go and find them. If every second sentence needs your pricing rules, your staff, your approval steps or your own words for things, that is what custom development is for.
The eight requests, and where each usually lands#
These are the ones that come up. The middle column is an honest default rather than a rule, and the right-hand column is what pushes a request past it.
| What you want | Usually | What tips it into custom work |
|---|---|---|
| Online booking | A plugin | Real staff calendars, deposits, cancellation rules, two things that cannot be booked at once |
| Quotations | A form plugin, then a person | Prices that follow your own rules, approval steps, quotes that change and need a history |
| Membership | A plugin | Tiers that have to stay in agreement with something outside the website |
| Customer portal | A plugin, if the data already lives in WordPress | The data lives in another system, which makes this an integration |
| Product configurator | A plugin, for plain variations | Options that constrain each other, live pricing, what your factory can actually make |
| Payments | A gateway plugin | Deposits, split payments, payouts to other sellers, unusual tax |
| Custom workflows | An automation service | When the workflow is the business rather than an errand around it |
| API integrations | Sometimes a ready-made connector | Error handling, retries, and deciding which side wins when the two disagree |
One pattern runs down that whole table. The visible part of each feature is nearly always solved already. What is not solved is the set of rules underneath it, and those rules came from you.
Booking is the one people get wrong#
A booking form is a calendar, a date, a name and an email address. Every plugin does that. If that is genuinely what you need, you are finished this afternoon.
Availability is the hard part, and it is invisible from the outside. Who is qualified to do this job, which of them is free, how long it takes, how much gap to leave afterwards, which room or machine it also occupies, what happens when somebody cancels the day before, whether a deposit was taken and what your rule is about giving it back. None of that appears on the screen. All of it is your business.
So the split is clean. The booking interface is a commodity and the availability rules are yours. Plenty of businesses find a plugin whose assumptions happen to match their own, and that is a genuinely good outcome. If yours does not match, be honest that you are buying a rules engine and only pretending to buy a calendar.
Quotations and configurators are the same problem#
They arrive as two separate requests and they are one. Both take a set of choices and turn them into a price, and in both the difficulty sits entirely in the rules.
A configurator whose options do not affect each other is a form. A configurator where picking one option rules out two others, changes the price of a third, and becomes impossible above a certain size is a small piece of software with your manufacturing knowledge inside it. Quotes work the same way. A fixed price list is a page. Pricing that depends on volume, distance, urgency and which customer is asking is not a page.
There is a cheap intermediate step that almost everybody skips. Publish the options, take the request, and price it by hand for a month. You will find out which rules you actually have rather than which ones you think you have, and about half the time the manual version turns out to be fine.
Payments are almost never the custom part#
This one is worth correcting, because it is where people expect to spend and it is not where the money goes.
Taking a card is solved. Gateways ship plugins, those plugins handle the compliance you should not want to touch, and connecting one is configuration rather than development. What is occasionally custom is not how the money moves but when: a deposit now with the balance on completion, a payment split between you and a subcontractor, a refund that follows your cancellation policy instead of the gateway's default.
If your payment request is really a rules request, say so when you ask for a price. It changes what gets built, and it changes the number.
When a plugin is the wrong answer#
Reuse first is a default, not a religion. Four signs the default has stopped applying:
- You are configuring around the plugin rather than with it, and the workarounds have started to need workarounds of their own.
- Three plugins have to co-operate to produce one outcome, and every update is a small gamble.
- It holds data you need somewhere else, and getting it out means exporting a spreadsheet by hand every month.
- It has not been updated in a long time, and the thing it touches is payments or personal data.
A plugin is code you did not write, running on your site, and each one is another thing to keep updated and another surface to watch. Take a backup before installing one you have not used before. If it needs an older PHP version to run at all, treat that as a real cost rather than a detail, and keep looking.
Why adding a feature is not rebuilding#
The fear underneath the original question is that adding something means starting the website over. On a real WordPress installation it does not, and the reason is worth seeing in mechanical terms rather than taking on trust.
Everything in those four routes arrives as an addition. A plugin installs alongside what is already there. A custom plugin does the same thing, written for you. A custom post type adds a kind of content the site did not have before. A template changes how one kind of page renders. An embed is a block on a page. An API call is code that runs when something happens. Not one of them requires touching the pages you have already published.
That is why the work lands on the site you already have, with no migration, no second website, and no change to the address your customers know. It is also why the order in the customization guide holds up. Generate, run the business, then add.
Reuse first, build later#
The mindset fits in a line: buy the boring version, find out what you actually need, then pay for the difference.
- Write down the outcome, not the feature. "Customers pick a slot and I stop losing Saturdays to phone calls" is an outcome. "A booking system" is a shopping list.
- Go looking for it. Most outcomes already have three or four products aimed squarely at them.
- Run the boring version for a month, even when the boring version is a form and a person.
- Note every place it hurt. That list, and not your original idea, is the scope.
- Then ask for a price on the difference.
A quote for "a booking system" prices somebody else's idea of one. A quote for "the four rules our current form cannot express" prices yours, and it is a far smaller number. Vague requirements are the usual reason software projects go over, and this is the cheapest possible place to make them precise.
It also guards against the quieter mistake, which costs just as much. Paying for custom work you never needed does not feel like a loss, because you do get something. You get something you now have to keep. The money side of that split is worked through here.
Start with a site that can take all four routes
Describe what you do and Sitebefy builds a real WordPress site you own, with the pages, layouts, content and SEO already in place. Because it is ordinary WordPress, a plugin, an embed, an integration or a custom-built feature can all land on it later without a rebuild. Look at the result before creating an account, and every plan carries a 14-day money-back guarantee.
Build my siteThe next time somebody asks for a feature#
- Say the outcome out loud without naming your company. If it survives, go shopping before you go scoping.
- Give the boring version a real month, with a real backup taken before you install anything.
- Keep a running note of what it could not do.
- Ask for a price on that note rather than on the original request.
None of this argues against paying a developer. It argues for knowing what you are paying them for, which is the part of your business that exists nowhere else. Custom development here starts with a description and a quote, and nothing is built until you accept it, so the scoping conversation is where the money is won or lost.
The website you have is not the constraint. It never was. The constraint is how precisely you can describe the one thing you do that nobody else does, and that is worth an afternoon long before it is worth an invoice.
