Web service or a regular website

“We need a website” often means very different things: a brochure with a form, a catalog with checkout, or an account area where clients work with data every day. Web service or regular website is not about “pretty”. It is about roles, logic, and how much of the business lives on the server.

When a regular site is enough

• the goal is leads, calls, trust: a landing page or corporate pages;
• content is edited in a CMS, without complex roles;
• there is no account area with order history / tasks / plans;
• integrations are light: form → CRM, a WhatsApp button.

That covers most landing pages and corporate sites. A store is closer to a service, but often still runs on a ready CMS — see launching an online store.

When you need a web service

1. Users sign in and see different content per account.
2. There are roles: client, manager, admin, partner.
3. The process cannot end with “a page + a form”: statuses, queues, billing.
4. You need an API for a mobile app or partners.
5. Load and data grow — a WordPress theme starts to crack.

Typical cases: industry CRM, school/clinic cabinets, subscription SaaS, a B2B portal. That is the zone of web services and SaaS: architecture, backend, admin, staged launch.

Timeline and budget

A regular site takes 1–6 weeks depending on type. A web service is more often 8+ weeks with a phased quote: prototype → MVP → integrations. Forcing a cabinet into a landing page usually costs more: rework after launch eats the budget.

Rule of thumb: if the value is content and a lead — a site. If the value is daily work inside the system — a service. The quote follows a brief: roles, entities, integrations.

Common choice mistakes

• start with a “pretty site”, then ask for an account area a month later;
• pick a website builder for complex logic and hit the ceiling;
• skip roles — the developer designs screens blind;
• forget admin and reports: “clients are fine, we are not”;
• compare a landing-page price to a SaaS build one-to-one.

An honest brief saves a month of debate. If you are unsure, write a scenario: what the user does in one session. That usually makes it clear — site or product.

Cannot pick a format?

Describe in two paragraphs who uses the system every day and what should happen after login. We will suggest site, store, or web service — and give a timeline and budget range.