10 mistakes business owners make when commissioning a website

Only about 31% of technology projects are completed on time, within budget and with a result that satisfies the client. Most of the causes arise before the first line of code — the ten most common mistakes and how to avoid them.

Commissioning a website is one of those investments that can either accelerate a company's growth considerably or turn into an expensive and frustrating experience, ending in a result that falls short of expectations, exceeds the budget and needs reworking within a few months. The industry figures are sobering — only around 31% of technology projects are completed on time, within budget and with a result that satisfies the client, and website projects are no exception in this respect, because web development falls under the same statistics: the remaining projects, roughly two thirds, are classified either as "challenged" (over budget or over schedule, or with reduced scope) or as failures. Most of these failures, however, have nothing to do with shortcomings in the technology or with incompetent developers — they are the consequence of human and organisational factors that arise before the first line of code is written, and they are entirely avoidable if the client knows which mistakes are made most often and how to steer clear of them.

In this article we look at the ten most common mistakes that business owners and organisations make when commissioning a website, and for each one we explain why it happens, what it leads to and what you can do to avoid it.

1. Deciding on price alone

This is probably the most common and the most expensive mistake made when commissioning a website — the client compares several quotes and picks the cheapest, on the assumption that a website is a website regardless of who builds it, and that the difference between a EUR 500 quote and a EUR 5,000 quote is simply the developer's profit margin. In reality that difference almost always reflects fundamental variations in build quality, the cleanliness of the code, the level of security, the scope for scaling and the support provided after handover, and the cheapest quote often turns out to be the most expensive solution in the long run, because poor-quality code creates what is known as "technical debt" — an accumulation of problems that demands constant fixes, limits how the site can develop and eventually forces a rebuild from scratch.

Low-cost quotes often conceal significant risks: the developer may use free or pirated themes that contain security vulnerabilities or hidden malicious code; the code may be unoptimised and unstructured, which makes later maintenance and extension difficult and costly; testing may be inadequate, meaning that defects only come to light after launch; and after-sales support may be minimal or non-existent, leaving you without help at the moment you need it most. The right approach is to assess quotes on value rather than on price — study the developer's portfolio, speak to previous clients, check the technical quality of the sites they have built, and understand precisely what is and is not included in the price, because a "cheap" quote often leaves out items that are standard in an "expensive" one, such as responsive design, basic SEO optimisation, security configuration or training the editors who will run the site.

That difference is worth working out to the end, because a cheap quote rarely collapses in the quote itself — it collapses in the invoice that arrives eighteen months later. Suppose the cheap site lasts that long and then has to be rebuilt: you pay the full price for the second build — our WordPress development starts at €2,500 — and on top of it come the content migration, a fresh round of text and images, and the 301 redirects from the old URLs, without which a year of accumulated search rankings disappears along with the old address structure. The saving, in other words, was not a discount but a deferred payment with interest. And if the site is hacked in the meantime through an off-the-shelf theme or an outdated plugin, recovery at our rates costs €90 per hour excluding VAT with a minimum of eight hours — that alone eats most of what was saved at the start. None of this means a cheap site is always the wrong choice: for three pages whose only job is to show contact details and opening hours, a ready-made template is a rational decision, and we say so. The mistake starts where the site is a sales channel but is bought as a business card.

2. Unclear requirements and objectives

The second most common mistake is starting a project without clearly defined requirements, objectives and expected outcomes — the client approaches a developer and says something along the lines of "I need a modern, professional website", without being able to state which features the site needs, who the target audience is, what actions visitors should take on the site and how the site's success will be measured. Such vagueness leaves the developer to make assumptions about what the client wants, and those assumptions often turn out to be wrong, which leads to disappointment on both sides and to work already done having to be redone, costing additional time and money. This vagueness is the main driver of scope creep — a phenomenon that affects more than half of all projects in the industry and means that new features and requirements not included in the original plan are continually added during the project, increasing costs and often extending delivery timelines considerably.

The remedy is to invest time and effort in a discovery phase before any development begins — this is the stage at which specific business objectives are set (for example, increasing enquiries by 30%, bringing the bounce rate below 40%, achieving an average session duration of over 3 minutes), user personas are developed, user journeys are mapped, the site structure and functional requirements are established, and a detailed specification is produced that serves as the reference document throughout the project. Having such a document protects both sides — the client knows what they will get for their money, the developer knows what is expected of them, and any change that goes beyond the scope set out in the document is formalised as additional work with its own budget and timeline.

The same boundary for a RAG project is set out in our guide to RAG for business documents: a pilot needs a defined corpus, user group and acceptance criteria, not merely a demonstration chat.

3. Overrating design and underrating engineering

The third mistake, particularly widespread among business owners, is an excessive focus on visual design while the technical side is ignored or underestimated — the client chooses a developer purely on how attractive the websites in their portfolio look, without asking about code quality, site speed, security practices, scalability or SEO optimisation. Visual design and technical development are two distinct disciplines, and a beautiful website that takes ten seconds to load, is vulnerable to attack and cannot be found in search engines is worth far less than a visually plainer site that is fast, secure and well optimised.

Research consistently shows that 53% of mobile visits are abandoned if a site takes longer than three seconds to load, and a one-second delay in page load time can noticeably reduce conversions, because, as an Akamai and SOASTA study found, a delay of just 100 milliseconds cuts conversion rates by up to 7% — these figures mean that site performance has a direct effect on your revenue, and no amount of attractive design will make up for mistakes in the technical execution. The right approach is to judge a developer not only on how their work looks, but also on how well they can explain their technical approach — what architecture they use, how they ensure site speed, how they approach security, and how they plan to scale the site as the business grows and requirements change.

4. Leaving SEO "for later"

Business owners very often see search engine optimisation as something that can be added to a website once it has been built, rather like painting a wall after the house has gone up, but in reality technical SEO is a fundamental part of a site's architecture, and building it in after launch is considerably more expensive, more complicated and less effective than including it in the development process from the very beginning. URL structure, page hierarchy, internal link architecture, heading structure, structured data markup (schema markup), image optimisation, Core Web Vitals metrics and the mobile device experience — all of these elements are far easier and cheaper to implement correctly during development than to rework on a finished site.

Google uses mobile-first indexing, which means that the mobile version of your site is the one by which Google assesses and ranks your content — if the mobile experience is poor, your rankings will suffer no matter how good the desktop version is. According to Statista, mobile commerce reached approximately 2.07 trillion dollars in 2024, and Google's data shows that between 2015 and 2017 mobile searches with purchase intent containing the phrase "near me" grew more than fivefold — mobile optimisation is not simply a "nice extra", but a business necessity, particularly for local companies that want to attract customers in their own region. The right approach is to set out SEO requirements in the request for proposal (RFP) as a mandatory part of development, not as a separate service billed on top. In practical terms this means that from the very outset the developer must plan an SEO-friendly URL structure, ensure a correct heading hierarchy (H1, H2, H3), implement structured data (schema markup), optimise images with alt text and modern formats, configure the XML sitemap and the robots.txt file, and ensure that site speed meets Core Web Vitals standards — on a finished site, these same changes can require a substantial architectural rebuild.

5. Ignoring content production, or leaving it to the last minute

The fifth mistake is one of the most common reasons why website development projects run late — business owners assume that content is something that can be "written up" at the last minute and focus all their attention on design and functionality, while the copy, images and other content elements remain unfinished right up to the end of the project. The problem is that design is built around content, not the other way round — if the content is not ready, the designer is forced to work with placeholder text (lorem ipsum), which leads to a design that does not match the volume and structure of the real content, and when the actual text is finally put in, the visual appearance can change dramatically, and not for the better.

Delay in preparing content is one of the most frequently cited causes of project overruns in the industry, and that is logical, because producing quality content takes time — the copy has to be written, aligned with the company's tone and message and optimised for SEO, and the images have to be selected or created so that they match the brand identity and the design requirements. The right approach is to treat content production as a critically important project phase with its own deadlines and owners, starting in parallel with the design work or even before it, rather than as an additional task to be done "when there is time". If the company has no in-house resource for producing content, it must be included in the project budget as a separate line item, bringing in a professional copywriter or content specialist.

6. No plan for maintenance after launch

The sixth mistake relates directly to the subject of maintenance, which we have already covered in our article on recovering hacked websites — many business owners regard a website as a one-off product that simply "works" once it has been built, and give no thought to what happens after launch, when security updates, content changes, bug fixes, performance optimisation and compatibility with new browser versions and devices will all be needed. This approach is dangerous, because an unmaintained website is an unprotected website — according to Sucuri, more than half of hacked CMS sites were running an outdated version of the software at the time of infection, and a widely cited Sophos estimate, now more than ten years old, refers to roughly 30,000 new sites a day on which malicious code is detected.

Maintenance has to be addressed at the project planning stage, not after the site has gone live, because it affects the choice of technology (some platforms are easier to maintain than others), budget planning (maintenance costs must be included in the total lifecycle budget for the site) and the choice of developer as well (you need to establish whether the developer also offers maintenance services and on what terms). Ideally, the contract itself already includes an after-sales support agreement (an SLA — Service Level Agreement) defining which maintenance work will be carried out, how often, what the response time is in the event of a problem, and what this service costs.

7. Handing control of the domain and hosting to the developer

The seventh mistake is one of those that can have the most serious long-term consequences, and yet it is made surprisingly often — the business owner lets the developer register the domain name and buy the hosting service in the developer's name rather than in the company's name, and in doing so loses control of business-critical digital assets. If the working relationship with the developer ends for any reason — whether amicably or as the result of a dispute — the owner can end up unable to access the domain or to move the site to another server, and may even lose the domain name altogether if the developer does not renew the registration.

The domain name and the hosting account are your business's digital assets, and they must be owned and controlled by you, in much the same way as your company's registered address or trademark — you would not let your accountant register your company's legal address in their own name, and for the same reason you should not let a developer control your digital identity. The right approach is to register the domain name yourself with a reputable registrar, to buy hosting in your own company's name or to rent it from a partner that hands over the configuration and the data on request and to give the developer only the technical access required to build and deploy the site, not administrative control over these resources. The same applies to Google Search Console, Google Analytics and other analytics and marketing accounts — they must be created in the company's name, with the developer granted access with limited rights.

8. Ignoring testing and quality assurance

The eighth mistake is that many business owners give too little attention to the testing process and accept a site without examining it thoroughly, trusting the developer's assurance that "everything works" — whereas in reality proper testing is a demanding and time-consuming process that involves far more than browsing the pages and pressing a few buttons. Inadequate quality assurance is one of the most common reasons why sites show defects after launch that affect the user experience, conversion and even security, and fixing them in a finished site is always more expensive and more difficult than it would have been to find and resolve the problems during development.

Testing should cover several dimensions: functional testing checks that every function of the site works correctly — forms, search, navigation, user registration, cart and checkout processes, content filtering and sorting; compatibility testing checks that the site works correctly in different browsers (Chrome, Firefox, Safari, Edge), operating systems and devices (desktops, tablets, smartphones with a range of screen sizes); performance testing assesses the site's loading speed, response times and behaviour under load; security testing identifies potential vulnerabilities such as SQL injection, scope for XSS attacks and incorrect access control; and accessibility testing checks whether the site can be used by people with various impairments, in line with the WCAG standards.

The right approach is to provide for a testing phase in the contract itself, with clearly defined acceptance criteria — which means it is documented what exactly will be tested, what results are acceptable and what the procedure is if testing uncovers problems. It is also advisable for the business owner to carry out acceptance testing personally or with the help of an independent specialist, rather than relying entirely on the developer's own assessment, because a developer testing their own work is like a student marking their own exam.

9. Decisions taken by committee with no single owner

The ninth mistake is organisational, and it is particularly characteristic of larger companies and organisations, where a website project involves several decision-makers — the marketing department, the sales team, management, the IT department and sometimes even the lawyers — and each of them takes part in approving the design and the content with an equal vote. This "design by committee" approach almost always leads to a result full of compromises that satisfies no one, because every decision-maker tries to press their own priorities and preferences into the site, and the end result becomes cluttered, inconsistent and disconnected from the business objectives.

Research and industry experience consistently show that projects with one clearly designated decision-maker, authorised to approve the design, the content and the functionality, are completed faster, stay within budget more often and achieve better results than those where decisions are taken by a group. This does not mean that the views of the other parties involved are unimportant — it means there has to be a clear process in which all parties can express their views and give feedback, while the final decision is taken by one person who is authorised and accountable for the outcome of the project. The RACI matrix (Responsible, Accountable, Consulted, Informed) is an effective tool for structuring such a process — it defines clearly who is responsible for carrying out the work, who is the final decision-maker, who must be consulted and who must be informed of decisions.

10. Ignoring intellectual property and contractual matters

The tenth mistake concerns the legal side of things, which many business owners — the owners of smaller companies in particular — tend to ignore or to regard as unnecessary bureaucracy: they begin working with a developer without a formal contract, without clearly defined intellectual property rights and without a non-disclosure agreement (NDA), which can cause serious problems both during the project and after it has been completed. Without clearly defined intellectual property rights, a business owner can end up in a situation where they do not in fact own the source code they have paid for, and the developer is free to use that same code for other clients, or even to refuse to hand the source code over if the working relationship ends early.

The contract should state clearly that all intellectual property created during development — source code, design files, graphics, data structures and documentation — belongs to the client once payment has been received in full, and that the developer has no right to use it for any other purpose without the client's consent. The contract must likewise cover the definition of the project scope, the deadlines, the payment schedule (preferably tied to the completion of milestones rather than to elapsed time), the warranty period, confidentiality provisions and the procedure for resolving disputes. A payment structure tied to specific, approved milestones (milestone-based payments) rather than simply to a period of time gives the developer an incentive to keep to the deadlines and ensures that the business owner pays only for work actually delivered, not for an indefinite amount of time spent; for larger and non-standard projects, a time and materials model with a weekly cap is also appropriate, provided that the scope and the cap are set out in writing.

A non-disclosure agreement (NDA) matters particularly where the developer is given sensitive business information during the project — customer data, business processes, pricing policy or other confidential information which, in the hands of a competitor, could damage your business. Many business owners assume that an NDA is an instrument for large corporations, but in reality it is equally important for any company that shares sensitive information with external partners. A well-structured contract with clear milestones and acceptance criteria also serves as a project management instrument — it ensures that both parties agree on what is being done, when it will be finished and what result is expected at each stage, and it substantially reduces the risk of misunderstandings and disputes as the project progresses.

Further mistakes when commissioning a website

Although we have described the ten main mistakes, several other common shortcomings deserve a separate mention, because they can materially affect the success of a website development project. One of them is relying too heavily on the developer's opinion in every matter, including business strategy — the developer is an expert in technology, but they rarely understand the specifics of your business, your target audience and the dynamics of your market as well as you do yourself, and if you delegate every decision entirely to the developer, you risk ending up with a site that is technically sound but ineffective in business terms.

The second common mistake is ignoring accessibility — many business owners are not even aware that their website has to be accessible to people with disabilities, and that in many jurisdictions this is a statutory requirement rather than simply good practice. Building accessibility in during development is considerably simpler and cheaper than adding it to a finished site, and it widens your potential audience, because roughly 16% of the world's population — 1.3 billion people — live with a significant disability.

The third further mistake is failing to implement analytics and conversion tracking — many sites go live without Google Analytics, Google Search Console or other analytics tools configured, which means that the business owner cannot assess how well the site performs, identify problems or take data-driven decisions about further optimisation. Implementing analytics must be written into the scope of the development project as a mandatory requirement, not treated as something to be "done later". Without analytics data you are effectively working blind — you do not know how many visitors your site attracts, where they come from, which pages they visit, where they drop off, or whether your site is fulfilling its business function at all.

The fourth further mistake worth mentioning is failing to ensure the site's legal compliance — many new sites go live without a privacy policy, a cookie notice, terms of use or the other legal documents required under the GDPR and other applicable legislation, and this negligence can have serious legal consequences, including fines of up to EUR 20 million or 4% of the company's total worldwide annual turnover — whichever is the higher. Legal compliance is not merely a formality — it is also a signal of trust to your visitors, showing that you take the protection of their data and their privacy seriously, and consumers today pay ever closer attention to how companies handle their personal data. The presence of a cookie banner is not enough; it must be technically tested, as we explain in our cookie banner audit guide.