When to say no to a website feature, before it costs a step

en 2026-09-27 7 min read

A feature belongs in your first build if the site cannot do its main job on launch day without it, and everything else can wait. The test earns its keep on the expensive features: a login, a customer dashboard, payments, a CRM connection or a chatbot each make a project step 04 work, at EUR 3.500-7.500.

A business website with a CMS, service pages and a booking or contact flow is step 03, at EUR 1.500-3.500. One feature can decide which of those two prices you pay, and whether the build takes 3-6 weeks or 6-12. Say "not yet" during scoping. Saying it after the fixed quote means reopening the scope.

The launch-day test

Picture the site live with one feature missing, then ask what a visitor does instead.

• If they cannot buy, book or reach you at all, the feature is a need.
• If they email, call, or fill in a form and you handle the rest by hand, it is a nice-to-have. It may still be worth building, but it has to earn its price.
• If nobody would notice it was gone, the answer is no.

A request can come from a customer who asked for it, from a competitor's site, or from an idea that sounded good in the meeting. Only the first arrives with evidence.

Which features move the step

On the ladder, pages move the price in small increments and functionality moves it in large ones. The full ladder of steps is on the pricing page. These requests stay below step 04.

A login, money moving through the site or a connection to another system changes the step, whatever the page count.

Each simpler version lets you test, with your own customers, whether the full feature is worth building.

Five questions to ask about any feature

1. Who asked for it? A customer request is evidence. A competitor having it is not, because you cannot see whether anyone uses theirs.
2. What does a visitor do today without it? If the honest answer is "they email us and that works", you would be paying to replace something that already works.
3. How often would it be used? Count it from your own records, such as last month's bookings or the questions that arrived by email. A feature used a handful of times a month has to be cheap.
4. Does it change the step? If it does, the feature has to be worth the whole jump between two price ranges, not a slice of it.
5. Who looks after it once it is live? A login or a payment flow needs updates and monitoring for as long as it runs, so its cost does not stop at launch.

"Not yet" is a different answer from "no"

A feature you cut from launch can be added later as an add-on: booking at EUR 350-750, payments at EUR 600-1.500, a CRM or API connection at EUR 750-2.500, or a chatbot at EUR 750-2.000. Care at EUR 100-300/mo covers updates, monitoring, backups and small fixes, not new features, so a later addition is new work with its own fixed price. You own the code, the repository and the database, so that work does not have to come back to the studio that built version one.

One thing to plan for: a login reaches further than most features, because it decides which pages are public, where customer data lives and how the database is laid out. It still bolts on, as an add-on at EUR 1.500-4.000, but if you are fairly sure it is coming, say so at scoping, so the first build leaves room for it. That kind of decision is part of how design and engineering work here.

How scoping sorts the list, and what it does to the weeks

1. You bring the whole wish list, unsure ideas included.
2. Each item gets one of three labels: launch, later or no. The launch-day test settles the easy ones, and the five questions settle the rest.
3. The launch list sets the step. The step sets the price range and the week range.
4. A fixed quote follows, written against that scope.
5. The build starts. Content is the part that waits on you, whatever the step.

A business website takes 3-6 weeks and an advanced site or web app 6-12, while a custom SaaS platform is timed after discovery. When one feature is the only thing holding a project at step 04, moving it to "later" drops the project a step, and the weeks drop with it. With a busy season coming, that can matter as much as the money.

When to spend less

Spend less if you are still finding out whether people want what you sell. A single-page landing at EUR 600-900, live in 1-2 weeks with a form and analytics, tells you more about demand than a dashboard nobody logs into.

Spend less if a feature is there to make the business look bigger. A chatbot on a site that gets a few enquiries a week answers questions a contact form would have handled.

Spend less if you are building your own product and the list already holds billing, an admin panel and user roles. That is step 05, from EUR 7.500 after discovery, and a step 04 web app with one working flow can show first whether it is justified.

And say yes when the feature is the business. If bookings are how you earn and you spend evenings confirming them by hand, the booking flow is a need. If you sell products online, checkout is the site's main job.

Questions buyers ask about cutting features

Will the studio tell me if I do not need something?

That is what the launch, later and no labels are for, and they go into the written scope. A feature you pay for and nobody uses makes the site look like it failed, which is bad for you and for the studio that built it. You still make the call, with the reasoning on paper.

A competitor has a customer portal. Do we need one?

Not because they have one. You cannot see how many of their customers log in. Ask your own customers whether they would use it, and count how often they contact you for the things a portal would show them.

Does cutting a feature always lower the price?

The clearest drop comes when a cut moves the project down a step, for example from step 04 to step 03. Inside a step, a cut moves the quote within that step's range. Either way, cut before the fixed quote, while the scope is still open.

Is a booking system a need or a nice-to-have?

It depends on how bookings reach you now. If people book by phone or email and nothing gets lost, a contact form can carry the launch. If handling bookings by hand is costing you missed appointments, it is a need, and a booking or contact flow sits inside a business website at step 03. Taking a deposit at the moment someone books is a separate feature, and that one is step 04 work.

If you have a feature list and want it sorted into launch, later and no before anyone quotes, send it over.