What It Costs to Add Features to a Website

The cost of adding a feature to an existing website is driven more by the codebase it lands in than by the feature itself. The same booking system is straightforward on a well-built site with version control and a staging environment, and expensive on a site with none of those. Before you can be quoted properly, someone has to look at what's already there.

That's an unsatisfying answer if you came here for a price, so this post explains exactly which conditions move the number and by roughly how much — enough that you can predict which bracket you're in before you ask anyone.

Want the short version for your specific site? Tell me what it's built on and what you want to add, and I'll tell you which bracket you're in and why — free. Get in touch.

Why the same feature costs double on an older site

This is the part that feels like developers being difficult, so it's worth explaining the actual mechanism. Four things make identical work take longer:

No version control

Without Git or equivalent there's no history and no safe undo. Every change has to be made defensively, manually backed up, and verified by hand, because a mistake can't simply be reverted. This is the single largest multiplier on the list, and it applies to every hour of the job rather than a fixed portion of it.

No staging environment

Changes get tested on the live site, in front of your customers. In practice this means work happens in cautious small increments, often outside business hours, with a rollback plan for each step. Setting up staging first is usually cheaper than working without it, even on a single project.

Outdated dependencies

New features generally need current libraries. If the site is several major versions behind, the upgrade comes first — and upgrades cascade, because bringing one package forward often forces others. This work is real, mandatory and almost never in the original quote, which is why it turns up as a surprise.

No documentation and no original developer

Someone has to read the code and work out what it does before changing it safely. On a small site that's an afternoon. On a large one with unusual decisions in it, it's a meaningful share of the total, and it's pure discovery cost — you get no visible feature for it.

If several of these describe your site, read taking over a website from another developer first. Fixing the foundation is often a better first purchase than the feature you came for.

What actually drives the price of each feature

Independently of the codebase, features differ enormously in how much genuinely new work they need. The useful question is how much of this is a solved problem you can rent, and how much is specific to your business.

One sourced datapoint on the multilingual row: Cyprus providers put adding Greek and English versions at roughly 20% on top of a project's cost (Cyprus Digital Agency). That's a fair rule of thumb for a two-language content site, though it understates the case where prices, tax rules or legal text differ per market.

The two features people most underestimate

Booking, because of the double-booking problem

A booking form looks like a form. The expensive part is invisible: two people can submit the same slot in the same second. Checking availability in the browser doesn't solve it, because each browser rendered a calendar that was accurate when it loaded and stale by the time it was submitted.

The fix has to sit at the point the data is written — a uniqueness constraint, a transaction, or a version check on the slot — and it's the difference between a calendar staff trust and one they quietly abandon for a paper diary. On the hospital system I built, that decision was made before any feature work started, because a calendar nobody trusts is worse than no calendar at all: it still has to be maintained. For price bands specific to this feature, see what a booking website costs.

Logins, because of permissions

"Let customers log in" is cheap. "Let customers, staff and managers log in and each see the right subset of the same records" is a different project, and the cost scales with the number of distinct answers to "who can see or change this?" rather than with the number of screens.

The rule that keeps it safe is that permissions are enforced on the server, not in the interface — the UI should only ever hide what the API already refuses. A hidden button is a convenience, never a security boundary. If your feature is heading in this direction, what a custom web application costs prices portals under the same roles-and-permissions driver, and the hospital management system case study is what it looks like built.

How to estimate the cost yourself

Since feature prices aren't published the way website prices are, the honest way to sanity-check a quote is to work backwards from hours and published rates. NZ hourly bands, from a provider that publishes them:

Full bands and context at Web Maniacs. Content changes and small tweaks on an existing site are commonly billed lower, at $50–$150/hr (Fuel Design). In Cyprus, ongoing freelance engagements run €500–€2,000/month against agency retainers of €3,500–€12,000+/month (Uveler).

So when you get a quote, ask for the estimated hours as well as the total. Two quotes at the same price can mean very different things — twenty hours from a senior developer, or forty from a junior — and knowing which tells you what you're buying.

When adding the feature is the wrong move

Three situations where I'd tell you to stop:

• The feature already exists as a product. Bookings, scheduling, help desks and newsletters all have mature hosted tools. A monthly subscription that solves it today usually beats a custom build you also have to maintain — and you can always build it properly later once you know it's load-bearing.
• You're adding the third or fourth major feature to an aging site. At that point you're funding a rebuild in instalments, at a worse price and with no coherent result. Published NZ ranges put a simple web app at $15,000–$40,000 and a mid-complexity platform at $40,000–$120,000 — worth comparing against the sum of what you're about to spend piecemeal.
• Nobody has asked for it. The most expensive feature is one built on an assumption. If you can't name the customers who'll use it, build the smallest version that tests the idea.

Frequently asked questions

How much does it cost to add a booking system to a website?

It depends far more on your existing codebase than on the booking feature itself, which is why no honest developer quotes it sight-unseen. The cost drivers are your availability rules, timezone handling, cancellations and reminders — plus the concurrency problem of preventing two customers booking the same slot, which has to be solved where the data is written rather than in the browser. If an off-the-shelf booking product fits your rules, it will almost always be cheaper than a custom build.

Why does adding a small feature cost so much?

Usually because of what surrounds it rather than the feature. If the site has no version control, no staging environment and outdated dependencies, every change has to be made defensively, tested on production, and often preceded by a library upgrade that cascades. That work is invisible in the finished result, which is why the price feels disconnected from what you can see.

Is it cheaper to add features or rebuild the website?

Add features while the foundation is sound and you're making one or two changes. Rebuild when you're on your third or fourth significant addition to an aging codebase, because at that point you're paying for a rebuild in instalments without getting a coherent one. Compare the running total you're about to spend against published NZ ranges of $15,000–$40,000 for a simple web app and $40,000–$120,000 for a mid-complexity platform.

How much does it cost to add a login to an existing website?

Simple customer accounts are relatively cheap because hosted authentication services handle passwords, resets and security. The cost scales with permissions, not screens: two roles is a feature, while six roles with overlapping rules about who can see and change each record is a project in its own right. Be specific about roles when you ask for a quote — it's the variable that moves the number most.

Can any developer add features to a site someone else built?

Yes, but they should look at the code before quoting a fixed price. An inherited codebase is another developer's decisions, and the work of understanding them can't be priced blind. Expect a short paid audit, then a real quote — and treat a confident fixed price offered without access to the code as either padded or about to become a variation invoice.

Where to start

Find out whether your site has version control, a staging environment and current dependencies. Those three answers put you in a bracket before anyone quotes anything, and any developer who has touched the site can tell you in an hour.

If you'd like that answered honestly — including whether an off-the-shelf product would serve you better than anything I'd build — send me the details. Get in touch, or see what I work on.