A simple HTML site, WordPress or a portal: what to choose and when
The three options clients most often ask about: a static site, a WordPress CMS and a custom system with personal accounts. A practical comparison — speed, price, maintenance and how far each one can grow.
Almost every project starts with the same conversation. The client says, "I need a website." We ask, "And what should happen to a request after that?" The answer to that question is what actually determines what to build — a static site, a WordPress site or a portal. Below is an honest comparison, without the "we love technology, so…" routine.
Three options in a nutshell
- A static site — a set of ready-made HTML pages. Delivered to the browser as-is, with no database and no admin panel.
- WordPress — a ready-made content management system: the site lives in a database, and you edit texts and pages yourself through the admin panel.
- A portal — a custom system for your process: personal accounts, roles, requests with statuses, payments, integrations with 1C and CRM.
| Criterion | Static site | WordPress | Portal |
|---|---|---|---|
| Load speed | Maximum | Depends on plugins and hosting | High with careful development |
| Who edits content | A developer | You, yourself, via the admin panel | You and your clients, each in their own account |
| Time to launch | Days | One to two weeks | From a month, in stages |
| Maintenance | Barely anything | Core, plugin and theme updates | Updates, monitoring, backups, tests |
| Ceiling for growth | Many pages — it gets unwieldy | Catalog, blog, landing pages, store | Processes, data, roles, integrations |
A static HTML site: when it is the best choice
- A business card site, a landing page for ads, a 5–10 page site with text and contacts.
- Content rarely changes: you update the price list once every six months — and that's enough.
- Speed and a good Lighthouse score matter: static files are served instantly, and they simply do not have the usual database or admin-panel vulnerabilities.
- The budget is limited, and you would rather not pay extra for an admin panel nobody will use.
The flip side: edits have to be ordered from a developer. If you plan to publish news yourself or change the structure every week, a static site will start to annoy you fast.
WordPress: when it is genuinely worth it
- You need a blog or news that you publish yourself.
- A catalog of products or services with descriptions, prices and images — without complex order logic.
- A store with payment and delivery built on ready-made scenarios (WooCommerce) — if your assortment and processes are standard.
- Your team has already worked with WordPress and knows how to use it.
Keep in mind: WordPress is not as simple as it looks. The core, plugins and theme need updating, plugins conflict with each other and with the PHP version, and its popularity makes it a target for automated attacks. We only put projects on WordPress where a CMS is genuinely needed, and we set up backups and updates right away.
A portal: when a website is no longer enough
- Different people need different permissions: a client sees only their own orders, a manager only their own deals, a director the whole report.
- A request goes through a path with statuses, and you need to see that path, not reconstruct it from chat logs.
- The same operations repeat: an invoice, an act, a payment reminder, an export to accounting.
- Data must live in one place and be exchanged with 1C, CRM or the warehouse.
A portal is not written all at once "from a big spec". The first stage is a minimally useful slice: an account with requests and statuses. From there it grows with real use, while the data schema and roles are designed up front so growth doesn't hit the foundation.
When a website needs to become a platform — seven signs
An example portal: how docase.ru is built
What we do in each case
- A static site — fast and inexpensive: quick load, markup for search engines, analytics out of the box.
- WordPress — when you need an admin panel: we set up updates, backups and caching so the site doesn't drift.
- A portal — a custom system in stages: first what removes the routine, then expansion based on actual use.
If you are torn between the options, describe what happens to a request after a client sends it. That is usually enough to see what to build. And yes: if a landing page is all you need, we will say so.
Facing something similar?
Tell us what happens today: where time gets lost and which operations repeat. We will suggest what to automate first.