How to Price Website Add-Ons, Integrations, and Extra Pages

A client emailed me two days after we’d agreed on a five-page site: "Oh, one more thing, can we add a booking calendar? Shouldn’t need a whole new quote, right?" I remember staring at that message for a minute, because on paper it sounded like a small ask, a single feature bolted onto a project that was already scoped. In practice, a booking calendar meant a new integration, testing across devices, a settings walkthrough for the client, and roughly six hours I hadn’t priced anywhere. That email is when I stopped treating "add-ons" as a footnote and started treating them as their own category of pricing decision.

If you’re trying to figure out how to price website add-ons, the first thing worth separating out is the difference between a page and a feature. A new page, if it uses the same template, layout system, and content structure as the rest of the site, is usually the cheapest kind of addition — freelancers commonly charge somewhere in the $150 to $500 per page range depending on complexity and whether new copy needs to be written. A feature is a different animal entirely. A booking calendar, a payment integration, or a membership area isn’t "one more section." It’s a new system that has to work correctly, interact with the rest of the site, and hold up when a real client’s customer uses it.

This distinction matters because website integrations pricing gets underestimated constantly when freelancers price by instinct instead of by category. A payment integration means setting up a payment processor account or connection, handling test transactions, thinking through what happens when a payment fails, and making sure the confirmation flow actually works end to end. A booking calendar means syncing availability, testing time zones, and making sure double-bookings can’t happen. None of that is "extra design work." It’s closer to a small project living inside a larger one, and it deserves its own line item, not a vague bump to the total.

“A new page is a small addition. A new feature is a small project.”

I’ve started keeping a rough mental price list for the additions that come up most often, because negotiating each one from scratch, in real time, on a call, is where freelancers tend to underprice out of pressure to sound agreeable. Having categories ready means the conversation becomes "here’s what that typically adds" instead of an improvised number you might regret the moment you hang up.

Here’s roughly how I break the common add-on requests into pricing categories:

The ranges matter less than the habit behind them: every add-on gets sized before it gets agreed to. On the SitePoint and freelance forums where this comes up constantly, the advice converges on the same core move — point back to the original agreement, name the new work as an amendment to that agreement, and provide a specific quote for it before proceeding. That framing keeps the conversation collaborative rather than confrontational, because you’re not refusing the request, you’re pricing it accurately.

One pattern worth watching for: clients rarely ask for one add-on in isolation. A booking calendar request tends to arrive alongside "and maybe we should take payment through it too," which quietly turns a scheduling feature into a scheduling-plus-payment system. Extra website features compound the same way scope creep does, just dressed up as individual small requests instead of one obvious expansion. Pricing each one as it lands, rather than batching them into a vague "sure, we’ll figure out the total later," keeps the running cost visible to both of you.

I also try to distinguish between an add-on the client is asking for now and one they’re only floating as a future possibility. "We might want a store eventually" doesn’t need pricing today, but it’s worth a note in the proposal that the current build won’t need to be rebuilt to support it later, if that’s true. Nothing frustrates a client more than paying for an add-on in month six that requires undoing part of what you built in month one, simply because nobody asked about it at the start.

Add-ons and scope creep are close cousins, but they’re not identical. Scope creep is often unplanned and incremental; add-ons are usually a specific, nameable feature request. Either way, the fix is the same: size it, name it, and let the client decide with real numbers in front of them. I go deeper on the incremental version of this problem in Scope Creep Is Not Free Work.

That booking calendar email ended up being a good project, once I went back and priced it properly instead of guessing. The client didn’t push back on the added cost — she pushed back on my first instinct, which was to just absorb it quietly because it felt awkward to ask for more money two days into a signed agreement. It’s never actually awkward to price real work. It only feels that way in the moment before you say the number out loud.