It is easy to overestimate a site’s features in both directions. You can pay for a personal account that nobody uses, or for a complex calculator that clients scroll past without filling in. Or you can save at the start and launch a site without what the work actually needs: requests get lost in email, the manager copies them by hand into a table, and the prices on the site do not match the price list.
Both mistakes cost a lot, only at different times. The first — right away, in the estimate. The second — later, in missed requests and rework. Below, how to tell a needed feature from an extra one, and what it is reasonable to postpone until launch.
How to tell whether a feature is needed
Every feature on the site should have an answer to three questions. Which process it serves: a sale, a booking, a calculation, handling of requests. Who will use it: a visitor, a manager, you yourself. And what will happen if it is not built.
The last question is the most useful. If without the feature the process simply becomes a little less convenient, it can be postponed. If without it the process does not work or needs manual work every day, it is worth including from the start.
Another check — frequency. A feature that is used every day pays for the development faster than one that is needed once a quarter. A rare task is sometimes simpler to handle by hand.
If you are looking for inexpensive website development, it is worth starting with the list of features. Each extra feature lengthens development and complicates support, so a reasonable first version usually contains only what the site cannot do its job without.
Forms, quizzes and calculators
People often hesitate over this choice. A simple request form is needed on almost any site. A quiz and a calculator — tools for particular situations.
I compared them in detail in a separate article on quizzes, calculators and ordinary forms, so here there is only a guide. A quiz with branching is useful when the client finds it hard to state the task at once, and the answers to several questions help the client and you understand what is needed. A calculator is justified when the price can be calculated honestly by a formula, and it matters to the client to see it in advance. If the requests are similar to one another and still need a conversation with a manager, a simple form is usually enough.
Complexity grows quickly here. A quiz with several scenarios, conditions and a cost calculation needs a separate estimate and testing, so it is worth building when it is clear which questions really distinguish one client from another.
Catalogs and filters
A catalog is needed when there are many products or services and the visitor needs to choose. Filters are needed when the choice has to be made by several parameters: size, price, material, purpose.
A filter that nobody uses usually means that the parameters chosen are not the right ones. So it is useful to write down in advance how clients choose a product when they call or write to a manager. Filters are built from those parameters, and not from every characteristic that is in the table.
Whether a cart is needed is a separate question too. In an online store the buyer puts a product in the cart and places the order himself. If the price depends on the conditions and a manager still confirms it, a catalog with a request is often more convenient. This decision is better made before the start, because the structure of the cards and the whole purchase scenario depend on it.
Personal accounts
A personal account noticeably complicates both development and support. It brings registration, password recovery, data storage, different access rights, and all of that has to be checked and maintained.
It is justified when the client returns to the site regularly and really needs to see their own history: orders, documents, bookings, access to course materials. If the client comes once, leaves a request and then talks with a manager, an account is not needed.
Sometimes the task of an account can be solved more simply. For example, by sending documents by email or giving access to materials by a link. This is not always as convenient, but for a first version it can be enough.
CRM and other integrations
An integration is needed when data from the site must get into another system without a manual transfer. The most common — passing of requests: into a CRM, into a table, to email, into a messenger. This is usually a simple setup, and it is almost always useful: a request that has to be rewritten by hand gets lost sooner or later.
Payment and delivery — also integrations. They are worth including at once if the site is meant to sell, and testing before launch on real scenarios: the payment went through, it did not, the order was cancelled.
It is harder when an exchange with external services is needed in both directions, or custom logic for processing the data. Such tasks require studying the service documentation, setting access rights and handling errors. I estimate them separately, as non-standard tasks, and only after it is clear which process they automate.
What to do at once, and what after launch
Many features are easy to add later, when the site is already working and it is visible how people use it. This does not mean they will not be there: the decision is simply made on real data, and not on assumptions.
| Usually needed at once | Can be added after launch |
|---|---|
| A request form and passing of requests to where they are expected | A quiz, if it is not yet clear which questions matter |
| A catalog and the main filters, if there are many products | Additional filters by secondary parameters |
| Payment and delivery, if the site sells | A personal account, if clients return rarely |
| Consent to personal data processing in the forms | A calculator, if the price is still calculated by hand |
| Analytics, to see how the site is used | Integrations that save time but are not critical |
This is a guide, not a rule. For one business a calculator — the main feature, without which there is no point in launching, for another — a pleasant addition.
I use the same principle in Telegram Mini Apps as well: first a working base, and payment, personal accounts and analytics — as the next stages, when it becomes clear that they are needed.
How to build in room for the site to grow
Postponing a feature is easier if the site is ready for it. So at the start it is useful to say not only what is needed now, but also what may be needed later. Then the structure, the page templates and the data are designed with room to spare, and a new feature can be added without rebuilding the site.
For example, if a catalog is planned in six months, the sections should be named and arranged so that the catalog fits into them naturally. If an account is possible, it is better to collect client data in one place from the very beginning.
I can take complex functionality on myself, and its volume is simply included in the estimate. To understand which set of features your site needs now and which later, describe the task in the quiz on the site. I will reply in person and propose a first version that can be launched.