Someone who tells a software house "I need a website" might mean a half-page with a form, or a system that employees and customers will work in every day. That difference sets the team, the process and the scope, so it is better to discover it before the quote and not after. This guide helps you define which product you are building. It does not replace the decision on whether to build an app, Web or No-Code at all, and it does not explain what sets a system's budget — there are separate guides for both. App, Web or No-Code: how to decide
Five products under the name "website"
The following split is based on the type table on the web development service page, and adds for each type the question it answers and the sign that you have already outgrown it.
| Type | The question it answers | A sign you have outgrown it |
|---|---|---|
| Brochure site | "Who are you, what do you offer, and how do I get in touch?" — a professional presence and a presentation of services | Customers ask to log in, see a status or upload documents |
| Landing page / campaign | "Does the visitor who arrived from this ad take the one action we asked for?" | You need to explain a lot, serve several audiences or keep content that is updated |
| Online store | "How do we sell products directly, including catalogue, cart, payment and shipping?" | The sale depends on a quote, an approval or a process that cannot be described as a shopping cart |
| Web system | "How do identified people do work in a process that persists?" — a customer portal, an admin system, an internal tool | A second side (suppliers, partners, sellers) wants to join and act on its own |
| Platform / marketplace | "How do two or more sides meet, communicate and transact through us?" | This is the widest type; here the sign is that what is missing is operations and growth, not another feature |
The full type table, including how we build each one, is on the service page. Websites and web systems — the product types
Seven questions that sort a need into a type
Answer according to how the business works today or should work on launch day, not how it will look in three years. Each "yes" points to the type in the second column:
| Question | If the answer is "yes" |
|---|---|
| Does the visitor only read and get in touch, without logging in? | Brochure site or landing page |
| Is there one message, one audience and one action — usually from a paid campaign? | Landing page |
| Do you sell products from a catalogue with a cart and payment? | Online store |
| Do users need to log in and see only their own information? | Web system |
| Do users enter data or advance a process that is saved from visit to visit (status, approvals, documents)? | Web system |
| Does the product need to talk to existing systems (CRM, accounting, inventory)? | A connected store or a web system — depending on the depth of the connection |
| Is a second side (suppliers, sellers, partners) supposed to join and act on its own, with you in the middle? | Platform |
When a site becomes a system
The line between a "site" and a "system" is where the product starts to remember things. A brochure site shows the same content to everyone; a system knows who the user is, what they entered yesterday and what they are allowed to see. Four signs say the line has been crossed:
- Identified users — there is a login, and information one person must not see in another's account.
- Roles — not everyone may do the same thing (customer, employee, manager, supplier).
- Data that is written — the product does not only display content the team uploads, but stores what users do.
- A process that continues — an action starts today and ends in a few days, with statuses, notifications and approvals.
Once any of them is present, you are building software and not content: there is a database, permissions, testing that covers processes and not only pages, and a need for ongoing maintenance. What a system includes beyond its screens — in the anatomy section of the software development page. Custom software development — the anatomy of a system
What widens the scope in each type
Still no numbers, but in order of weight: these are the things a vendor will ask about for each type, and that you should arrive with an answer to.
| Type | Scope drivers | What to prepare before a call |
|---|---|---|
| Brochure site | Number of page types (not number of pages), languages, self-service content management, existing or new branding, connection to marketing tools | List of services, who writes the content, who will update it after launch |
| Landing page | Number of variants to test, measurement events, connection to forms and the CRM | The one action, the traffic source, and what counts as a conversion |
| Online store | Catalogue size and product complexity (variants, bundles), payment methods, shipping, inventory, connection to accounting | Where inventory is managed today, who handles returns, which documents the customer receives |
| Web system | Number of roles, number of entities (customer, order, document), processes and statuses, integrations, migrating data from an existing system, training and rollout | Who the users are, what each role does, how the process works today (even in a spreadsheet), and what happens when it stalls |
| Platform | Everything in a web system, plus: a separate experience for each side, vetting of suppliers or sellers, payments between the sides, ratings, trust mechanisms and operations (back office) | Which side joins first and why, what makes the other side stay, and who operates it day to day |
How an estimate for a web system is built from these drivers — and which costs are hard to see at the start — is covered in the budget guide. Web system budget: what to define before asking for a quote
Three examples from published projects
The following three are web products you can open today. None of them is a brochure site, which is why they show well where the line falls. The details here are only what the case-study pages themselves present.
Michrazit is a tender platform for private construction with two types of users — homeowners and suppliers — and each is onboarded, acts and sees the tender differently. That is the classic sign of a platform: a second side acting on its own, and a defined process connecting them, from tender to contract. Case study: Michrazit
JUSK is an employee onboarding system: forms, training, tests and mandatory tasks in one path, with access opening only after the employee completes what is required. It has a separate experience for the employee and for the team that manages it. It is a web system and not a platform: it has roles and a continuing process, but no two-sided market. Case study: JUSK
KICK AI is an interactive gaming platform connected to live football broadcasts: users take part in short rounds during the match and get an immediate result. Here the deciding sign is time — a web product that responds in real time, with an admin system behind it, is software in every sense, not a page being served. Case study: KICK AI
A marked example: "a website with appointment booking"
| Question | Answer (example) | What it means for the type |
|---|---|---|
| What does the visitor do? | Reads about the doctors and services, and requests an appointment | A brochure site, with one prominent action |
| How is the appointment set? | A form, and the front desk calls back | No system needed; the form connects to a tool you already have |
| And if the appointment is set automatically against the doctors' calendars? | Needs real-time availability, preventing double booking and sending reminders | This is already a web system: data that is written, a calendar connection, a continuing process |
| And if patients want to see history and documents? | Login, permissions and the privacy of medical information | A web system with security and privacy requirements that must be defined up front and checked with legal counsel |
What we do at this stage
In the discovery meeting we start from this question: which of the types are you building, and what from the next type is truly needed already in the first version. Then we define the scope drivers of the chosen type, and only then build. Our service for websites and web systems describes the types and how we build each of them. Websites and web systems
When the product is a system with roles, processes and integrations, it is built as software development in every sense — with the processes specified, a data model and permissions defined before the code. Custom software development — the anatomy of a system
And for every type, even a simple brochure site, the user experience decides whether the visitor takes the action. Experience and interface design happen before development, not during it. UI/UX design