How much does a website cost? Prices, scope and upkeep

DigiDraft prices: a starting point for your budget

These figures come from DigiDraft’s public price list, checked on 8 October 2026. They are indicative amounts in PLN excluding tax, not market averages. The project proposal confirms scope, applicable taxes, materials, integrations and schedule. A starting price is not a ceiling for unlimited additional features.

Start with tasks, not page counts

Write down who will use the website and what they should be able to do. A business offering one service needs a different structure from a manufacturer with a catalogue and several audiences. Ten similar product pages may involve less work than one substantial configurator.

List page types and functions: languages, search, forms, payments, content editing and integrations. Mark which are necessary at launch. You can then compare proposals against the same requirements.

Compare proposals line by line

Create a simple comparison sheet with a task, deliverable, owner, number of review rounds and acceptance condition. Include discovery, structure, writing, design, development, migration and handover. For each supplier mark the task as included, extra, supplied by you or unclear. Unclear does not mean free. Ask for the missing information before choosing the lowest number. This also exposes the work your staff would need to complete even when it does not appear on the agency invoice. Their time is part of the project too.

For example, one proposal might cover five screens adapted from a theme, while another includes six custom layouts, rewritten service descriptions and imported articles. Page count does not explain the difference. Check whether both options answer the same customer questions and allow you to add a service later. Equally, a higher price does not establish quality. Ask what work each line buys and what you will review when it is finished. Keep the comparison alongside the agreed brief so later decisions use the same assumptions.

Choose a delivery model for your actual needs

A template can be sensible when the offer is simple, content is ready and the layout needs no unusual behaviour. Costs change when a theme must be extensively rebuilt against its original structure. Ask about layout restrictions, updates and paid extensions. Request a mobile demonstration with your real heading, photograph and enquiry form. A polished demo using short English labels tells you little about a detailed service description or longer translated navigation. Test the content you intend to publish, not only the vendor’s sample.

Custom design makes sense when a complex service needs explaining, different customer groups need different routes or the brand needs a distinctive visual language. The work may include original illustration, prototypes and decisions about hierarchy. A catalogue, customer account or product configurator introduces data modelling and failure states as well. Rather than choosing a technology because its name is familiar, discuss who will edit the site, how often and what data moves between systems. Establish what remains usable if the supplier relationship ends. Each delivery model can work when the intended result and its limitations are explicit.

Include failure handling in integration costs

A contact form might prepare an email locally, send a message through a server, create a CRM record or qualify a project through several steps. These are different scopes. Record where the data goes, who receives it and how a visitor knows their request was actually accepted. Include validation, spam protection, limited data collection and an agreed failure message. A cheerful confirmation on screen does not by itself demonstrate that a message reached the intended recipient. At handover, check that the message reaches the person responsible for handling it.

Consider this example: the CRM is temporarily unavailable when someone submits an enquiry. Is the information retained appropriately for another attempt, or does the visitor receive an honest error? Who notices the problem? Similar questions apply to a cancelled payment or a booking slot that has just become unavailable. A proposal should identify test environments, supplier documentation and ownership boundaries. If investigation is required before a reliable estimate, ask for a defined discovery deliverable: supported options, risks and an implementation scope. One visible button can depend on several systems, so its apparent simplicity is a poor basis for estimating the work behind it.

Allow for the history of an existing website

Before replacing a website, inventory page addresses, articles, downloads and project pages. Identify addresses that receive search traffic or appear in campaigns, directories and printed materials. Google treats URL migration as a process involving old-to-new mapping and redirects. Keeping the domain does not preserve every path below it. An article moved to a new address needs a considered destination; removing a service needs a decision about what its previous visitors should find. Include these decisions in the scope before approving the new navigation.

Agree who creates the inventory and who decides which content should be retired. Avoid sending every old address to the homepage without checking relevance. Review internal links, images, documents and language equivalents as part of the move. Domain ownership and analytics access also need an owner. Passwords do not belong in a quotation brief; grant suitable access later through the agreed process. After launch, someone needs to inspect important addresses and reported errors. A quote covering visual redesign alone may omit this entire continuity task even though customers and search engines will still use the old routes.

Build the schedule around dependencies

Schedule work according to what must exist before the next step can be completed. Designing a detailed service page needs an agreed service scope. Translation needs stable source copy. A delivery test needs a functioning message destination. If materials do not exist, make their production a named stage with an owner. Saying they will arrive later merely moves the uncertainty. Appoint one person to combine your company’s feedback, resolve contradictions and approve a coherent response. Otherwise, the supplier receives several incompatible versions of the same decision.

Distinguish a correction from a scope change. Repairing a form that fails an agreed requirement is a correction. Adding another language after design approval changes the work. Agree how cost and schedule effects will be presented before extra work starts. Keep a short decision record stating the change, its purpose and approval. Everyone can then refer to the same approved version. If launch has a fixed date, define a smaller complete release and a specific later backlog. Essential contact, readable content and usable navigation should still function at launch; they are not finishing touches that can be postponed without affecting the customer’s journey.

Estimate a year of use as well as launch

Add recurring charges and editorial work to the initial project cost. Record domain, hosting and licence renewals, billing frequency, currency, taxes and account ownership. Check whether introductory pricing differs from renewal pricing. You do not need an artificially precise forecast; you need to know which bills will exist after acceptance. Put optional development, such as another language or a booking module, in a separate column. This prevents future ambitions from obscuring the actual cost of keeping the agreed first version operational.

Ask what maintenance includes: updates, backup creation and restoration, incident reporting, support hours and the treatment of additional work. The word support is difficult to compare without these details. Also agree how files, data, documentation and licences will be handed over if the relationship ends. A useful calculation is project delivery plus renewals plus planned content plus maintenance. Use the current quote and renewal prices from your domain, hosting and software providers. This makes the budget a practical ownership model and helps you judge whether your company can operate the website effectively after buying it.

Send a brief that produces a usable estimate

Describe the business in one sentence and name the main task a customer should complete. Include the current website, services, audiences, languages and required functions. List the copy, photographs and brand materials already available, together with the person who can approve them. If you share references, explain the useful part: package comparison, illustration, project presentation or motion. A request to make it modern leaves too much room for interpretation. Share a budget range and which features could wait. This gives the supplier a basis for proposing priorities rather than guessing your expectations.

During the discussion, walk through one route from arrival to contact. What information appears, what could prevent completion and how will you test the finished process? Then agree acceptance conditions, material-dependent dates and change handling. Written answers can feed directly into the scope and schedule. If you are preparing a website project, send DigiDraft the existing address and a short description of the change through the contact page. You do not need to choose a framework or prepare the full architecture first. Start with your goal, constraints and available materials so the conversation can establish what the project actually needs.