What Does a Website Cost in Austria? A Practical Guide to Scope, Price, and Ownership

Start with scope, not a headline number

“What does a website cost?” sounds like a precise question, but it leaves out the information that determines a useful answer. What must the site achieve? Who prepares the content? Which functions belong in the first release? Who will operate and update it afterward? A focused company website, an editorial site, and an online shop may all use familiar screens, yet the work behind them is very different.

Even two sites with the same page count can require different research, writing, layouts, integrations, testing, and handover. One might reuse a small set of components and arrive with approved copy. The other might require a new information structure, several content owners, complex forms, and migration from an older system. A single number hides those differences.

The more useful question is: “What defined result are we buying, and what responsibility remains with us?” That question turns an abstract purchase into a scope that can be reviewed. It also makes competing proposals easier to compare because each line can be connected to an outcome, an assumption, or a task.

This is particularly valuable for small Austrian businesses without an internal digital department. A founder, office manager, marketer, or subject specialist may have to supply material while doing their normal work. A clear scope shows where their involvement matters and prevents internal effort from becoming invisible.

Working principle: compare the result, included work, your contribution, ongoing operation, and handover before comparing the total.

This article does not invent a general industry figure. For AVM Forge, the current package catalog and selectable options remain authoritative. The catalog-backed website cost guide presents those details. The purpose here is to explain how to interpret them and how to prepare a sound comparison.

The five layers behind a complete website price

A website project can be understood in five layers. The amount of work in each layer varies, but every serious comparison should at least consider all five. This avoids treating the visible design as if it were the whole delivery.

1. Business objective and information architecture

The first layer defines the job of the site. It might explain services, attract suitable enquiries, prepare a booking, sell products, support recruiting, or help existing customers find information. That objective shapes navigation, page priorities, and the actions offered to visitors.

Information architecture is more than a menu. It groups questions in language the audience understands, separates primary journeys from supporting material, and establishes a sensible order. The work may be light when the business already has a clear structure and approved terminology. It is larger when audiences, offers, and messages must first be untangled.

The scope should therefore state whether structure is supplied, adapted, or developed within the project. Without that distinction, two proposals can appear to include the same pages while solving very different problems.

2. Content and editorial preparation

Copy, images, service explanations, proof, and product data shape the finished experience. A five-page website built from approved material is not the same engagement as five pages that need research, writing, editing, and several rounds of internal approval.

Content also affects the sequence of design and development. Real headings define hierarchy. Real paragraphs reveal whether a layout remains readable. Images determine crops, file sizes, and art direction. Temporary sample material can support early exploration, but it cannot validate the final page in the same way.

A useful proposal makes these responsibilities explicit:

• who supplies copy and media,
• when the material will be ready,
• who reviews factual statements,
• which editorial work is included,
• and how later additions are handled.

When a business supplies its own material, that is a genuine contribution to the project. It reduces external work only when the material is complete, suitable, and available at the agreed time.

3. Visual system and reusable components

Visual design includes typography, colour, spacing, hierarchy, interaction states, and the rules that make pages feel related. A strong result does not require every section to be unique. Reusable components can create a distinct identity while keeping the experience consistent and easier to maintain.

The effort depends less on page count alone than on the number of different design problems. Five service pages using one tested pattern are more predictable than five campaign pages with unrelated layouts and behaviour. An existing brand system can reduce some choices, but it still needs to work across navigation, forms, mobile screens, long text, focus states, and error messages.

This layer should be described in terms of systems and decisions, not only the number of mockups. The goal is a coherent interface that survives real content and multiple screen sizes.

4. Implementation and quality controls

The browser output is only the visible part of implementation. A dependable site also needs semantic structure, responsive behaviour, clear form feedback, metadata, redirects, error handling, and a route model that search engines and people can understand. Keyboard access, readable contrast, predictable focus, and robust no-script behaviour may also belong in the delivery.

Quality is not a final decorative pass. It comes from choices throughout the build. A content model that reflects the business is easier to update than scattered strings. A native link is easier to operate than a generic element repaired with extra scripting. A documented route is easier to migrate than an accidental URL.

When comparing proposals, ask what is tested and what “finished” means. A screenshot-perfect desktop page does not demonstrate mobile behaviour, content editing, form failure states, or production routing.

5. Operation, maintenance, and handover

The project does not stop creating work when the site becomes public. Domain management, hosting, software updates, backups, content changes, and account access still need owners. Some teams want direct editorial control. Others prefer occasional help. Some need a separate operating relationship for regular technical and content tasks.

That preference affects the platform and the handover. Current AVM Forge package terms describe the included hosting period, separately agreed Care, and the option to transfer away. The maintenance and Care overview explains that service area. The essential comparison point is that ongoing operation remains visible rather than being folded into an unclear project total.

Decisions that commonly change the scope

The following questions appear in many website projects. They are not universal surcharges. They are the inputs needed to define the work consistently.

The table is a checklist, not a calculator. A short contact form can be tightly bounded. A multi-step workflow with uploads, conditional questions, and several recipients is a different piece of software. A second language is predictable when approved translations exist, but more involved when each audience needs a different structure.

Page count is a useful proxy, not a complete specification

Packages often use pages as an understandable unit. That works when everyone shares the same definition. A new page using an established content pattern is not equivalent to a custom interactive tool that happens to live at one URL.

AVM Forge models one configurable dimension for each package in its catalog. The website packages use additional page scope; the shop package uses the initial setup of additional products. Those units do not claim to measure every possible project. They define the repeatable work that can be priced through each package.

Content readiness influences both effort and timing

Development can begin before every sentence is final, but a dependable release needs real content. Headings affect hierarchy, paragraph length affects rhythm, and imagery affects geometry. Late changes may be reasonable, yet they can reopen decisions that appeared complete.

A simple readiness list helps:

1. complete and approved,
2. available but needs editing,
3. must be created,
4. depends on another person or provider,
5. intentionally planned after launch.

This list does not produce the content. It makes ownership and dependencies visible. A proposal can then state which categories are included instead of relying on an ambiguous phrase such as “content support.”

Features need concrete user scenarios

“Contact form,” “booking,” and “customer area” are category labels. A workable scope describes what the visitor does, which information the system needs, what successful completion creates, and how failure is communicated.

A small scenario might read:

The visitor chooses a service.
They submit a name, contact method, and message.
The system checks the input and displays a clear status.
The enquiry reaches the agreed recipient.

This is not a full technical specification. It is enough to distinguish a straightforward enquiry from a calendar connection, CRM workflow, or internal case-management process. The more exceptions and external dependencies a feature has, the more carefully its boundary must be defined.

Separate project work from ongoing responsibility

A common comparison error is mixing the initial build with later operation. The build delivers the agreed website. Operation keeps the domain, hosting, and technical environment available. Editorial maintenance updates content. Further development introduces new page types, integrations, or workflows.

These areas may be offered together, but they should remain readable as distinct responsibilities:

• Project: structure, design, implementation, agreed content work, and release preparation.
• Operation: hosting, technical environment, and renewal of required services.
• Maintenance: updates, checks, backups, and agreed content changes.
• Further development: new functions, integrations, or substantial structural work.

A lower initial total can still require significant internal time later. A more structured initial build can require more project work while making future updates easier to understand. Neither observation decides the right choice on its own. The right distribution depends on the team, the pace of change, and the importance of the site to daily business.

Maintainability is a business concern

Maintainability means future changes can be made without rediscovering the entire project. Clear components, organised content, documented access, and a controlled technical base all contribute. This matters outside development: it affects onboarding, editorial confidence, incident response, and the ability to change provider.

Ask more specific questions than “Can we edit it?”:

• Which content can our team update directly?
• Which changes require technical work?
• Where are the domain, repository, media, and accounts held?
• What exports and credentials are provided at handover?
• How are larger additions scoped later?

The answers reveal whether the proposed operating model fits the business. A feature-rich editor is not automatically helpful if nobody owns the publishing process. A simpler setup is not automatically restrictive if the content rarely changes.

A binding configurator is different from an estimate

Many online calculators collect a few answers and produce an indicative range or a request for a follow-up call. That can be appropriate for open-ended work. It is not the same mechanism as a catalog with defined options and a binding configured amount.

The AVM Forge configurator uses entries from the package catalog. The server recalculates the selected options and quantities from that source. While the request stays within the package’s online-priced boundaries, the flow shows the binding final amount before the next step. The homepage package section, package detail pages, and configurators belong to the same catalog-backed path; there is no separately maintained editorial calculator.

The principle can be summarised as:

defined catalog + selected scope = binding configured price

An estimate is guidance for work that has not yet been fully defined. It remains useful when the solution must be discovered before it can be priced. AVM Forge therefore treats special builds and automation differently: scope is clarified together and a fixed amount is established before work starts. The services overview separates those paths from online-configurable packages.

What “binding” applies to

The binding amount applies to the specific package configuration and its documented boundaries. It does not turn every later idea into part of that selection. A new page type, new external system, or materially different workflow changes the work and needs its own scope.

That is why the review step matters. Package, quantities, options, and responsibilities should be read together. The useful feature is not speed alone; it is the visible relationship between each selection and the resulting amount.

When clarification is the better tool

A catalog suits repeatable work with stable boundaries. Clarification is better when the project connects several systems, contains unusual data flows, or begins with an outcome that is not yet specific enough to build.

Signals that the work is still open include:

• multiple external systems with unknown access rules,
• custom roles and permissions,
• migration from data that has not been inspected,
• workflows with many business-specific exceptions,
• or an objective that first needs a prototype.

This does not make the project less suitable. It means the uncertainty should be resolved through discovery rather than hidden inside a generic package selection.

Three package types and three cost structures

AVM Forge currently presents three configurable packages: Starter, Standard, and Webshop. Their names matter less than their intended uses. Current scope, options, and price ranges are published in the website cost comparison and on the linked package pages.

Starter: a focused company presence

Starter is designed for a clearly bounded static site. Its cost structure follows a focused page scope and selected additions. It is suited to a business whose core services, contact route, and essential information are relatively stable and which does not need a content management system in the base package.

The decision is not simply whether Starter is “small.” The useful question is whether the defined pages and functions cover the actual communication need. If the team plans regular articles, broader editorial work, or more extensive content, a different package may describe the operating model better.

Standard: structured self-managed content

Standard combines a broader company site with a CMS and blog for content the team can manage. That introduces an editorial responsibility alongside the initial build. Someone still needs to write, review, and publish. The system enables the work; it does not replace ownership.

When comparing CMS offers, look beyond the presence of an editor. Which content types are modelled? Which page patterns are ready? Who will maintain the material after handover? The business websites overview gives more context for this use case.

Webshop: initial setup is not later self-management

For Webshop, the configurable product quantity prices the initial setup performed by AVM Forge. It is not intended as a permanent cap on products the business may manage later. After launch, products can be added and edited through the product CMS. Special point-of-sale, marketplace, inventory, or ERP connections require separately defined work.

This distinction shows why the word “product” alone is incomplete. A product may arrive as clean structured data, or as a collection of partial descriptions, variants, and images. Clarify who prepares the data and which external systems are involved. The webshop service overview explains the boundary between initial setup, later self-management, and special integrations.

A repeatable method for comparing proposals

A small comparison matrix prevents one attractive line from dominating the decision. It does not need complicated scoring. It only needs the same questions applied to each option.

Step 1: Describe the outcome in one paragraph

State the audience, primary task, planned content, desired editing model, and next action for visitors. Avoid platform names initially. “A bilingual company site that explains three service lines, presents selected work, and sends suitable enquiries to our team” is more useful than “a modern CMS website.”

This paragraph gives providers a shared target and helps internal stakeholders recognise when a requested feature does not serve it.

Step 2: Separate must, should, and later

Not every worthwhile idea belongs in the first release. Divide the requirements into three groups:

1. Must: the release does not achieve its purpose without it.
2. Should: valuable, but can be added in a planned follow-up.
3. Later: recorded without enlarging the current project.

This protects the core objective while leaving room to learn. It also reveals proposals that present many optional extras as though they were essential to launch.

Step 3: Write assumptions beside the price

Every proposal contains assumptions. It may expect final copy, one language, prepared product data, or access to existing accounts by a certain date. Put those assumptions next to the relevant line. A wrong assumption can change the project more than a small difference between totals.

Step 4: Understand review and change boundaries

Ask how design and content reviews are organised, how feedback is consolidated, and what counts as a revision. More feedback loops are not necessarily more useful. Clear decision ownership and grouped comments usually produce better progress than scattered messages from several people.

Also distinguish correction from expansion. Adjusting supplied text is not the same as adding a new page type. Repairing agreed behaviour is not the same as introducing another system. The proposal should make that boundary understandable without requiring technical vocabulary.

Step 5: Include the post-launch model

Record who holds the domain and accounts, how access is handed over, how content will be updated, and what separate support is available. A project is easier to evaluate when the route to independent operation or a later provider change is clear from the beginning.

Common mistakes when reading website prices

Treating the starting price as the selected total

A starting price describes a base. It does not include every scope choice by default. AVM Forge’s cost guide therefore distinguishes the package floor from the complete online-configurable range. The concrete configured selection remains the source for a particular order.

Confusing a platform with an outcome

A CMS, framework, or shop platform is a tool. The business result also depends on structure, content, implementation, operation, and ownership. Two projects using the same platform can have very different work. Different technical approaches can also serve the same objective.

Valuing internal contribution at zero

Business-supplied copy and images reduce outside work only when they arrive ready to use. Internal coordination consumes real time even if it does not appear on a provider invoice. A sensible comparison accounts for available people, decision speed, and competing responsibilities.

Treating launch as the finish line

Once the site is public, measurement, content updates, account management, and technical upkeep begin. Not every business needs an ongoing service relationship. Every business needs a clear owner for stale content, access problems, and future changes.

Calling every later request a small change

“One quick addition” may be a sentence or a new application. Describe an addition by its behaviour and dependencies. This keeps the initial scope reviewable and reduces mismatched expectations later.

Prepare these facts before configuring or requesting a proposal

A short internal brief can make the next step much more productive. Gather:

• the website objective in one sentence,
• primary audiences and their main questions,
• expected pages or product areas,
• content that exists and content still missing,
• required languages,
• forms and external systems,
• desired self-management after launch,
• one person responsible for consolidated approval,
• and a preferred release window with known dependencies.

Mark uncertainty honestly. “Not decided” is useful information. For a bounded package, the configurator shows which selections can be priced online. For open work, the brief becomes the starting point for defining scope together.

Use the right AVM Forge source for each decision

This article provides context and deliberately avoids becoming a second store of changing catalog values. Use the existing destinations for current details:

This separation is intentional. If the catalog changes, the article should not preserve an outdated amount or option. The linked commercial pages derive their details from the same authorities that support the package display and configuration flow.

Conclusion: a readable scope makes price meaningful

A sound website decision does not begin with the smallest visible number. It begins with a clear objective and a shared description of the result. Pages, content, languages, functions, implementation quality, self-management, operation, and handover form the complete scope.

For clearly defined AVM Forge packages, the configurator connects those selections to a binding price. For special websites and business automation, clarification before a fixed quote is the cleaner path. Both methods follow the same principle: uncertainty is made visible and resolved before work starts.

When comparing options, place five things side by side: the result, included work, your contribution, ongoing responsibility, and handover. The broad question about website costs then becomes a concrete business decision—one that reflects how the organisation actually communicates, approves content, and maintains its digital presence.