The client says they need a website. This sounds like a specific request, but it isn't. It's not yet clear why the website should exist, who it should help, what it should change within the company, or how we'll know it's met its goals. "I want a website" is the beginning of a conversation, not a specification.

The client doesn't need to be a website developer. They know their business, their clients, and their problems, but they don't need to understand the interrelationships between content, usability, accessibility, performance, SEO, infrastructure, and subsequent maintenance. Nor should they pretend to. The developer's job isn't to thoughtlessly convert every request into code. It's to understand the business goal, translate it into requirements, and explain the implications of the available decisions to the client.

Therefore, the pre-website interview isn't a sales formality. It's the first part of the design process.

Client describes the solution, but you have to discover the problem

I've observed the same principle many times: the client doesn't yet know exactly what they want. Sometimes they only have a general idea. Sometimes they show a competitor's website and ask for a similar element. Other times, they present a very specific requirement that turns out to be an anti-pattern—a popular or familiar solution that doesn't serve its true purpose.

This isn't the client's fault. No one lives inside another person's head. Until expectations are articulated, they can't be honestly met. Even a stated expectation must still be linked to the question: "What is this supposed to achieve for the user or the company?" Mature service design methods also separate the need from the proposed solution and recommend first understanding the full user context (GOV.UK, "Learning about users and their needs").

A client might say they need a blog. However, a blog itself is merely a mechanism for publishing content. It doesn't automatically create brand expertise, traffic, or sales. It requires valuable content, systematic work, and audience outreach. Google explicitly states that even meeting technical requirements and best practices doesn't guarantee indexing or displaying a page in search results (Google Search Essentials). It also recommends creating useful content for people and actively informing relevant communities about the site (Google, "Creating helpful, reliable, people-first content").

A blog makes sense when it helps a potential customer better understand the problem, assess the company's competencies, and make a more qualitative purchasing decision. If a company doesn't intend to create or promote content, this should be stated before the quote, not months after launching an empty "News" section.

One interview isn't enough, because the site has many layers.

I divide the interview into several areas. First, you need to understand the general needs and determine the type of implementation: whether you need a simple website, a personal website, a corporate website, a store, or perhaps the problem leads you towards a more complex application. At the same time, you need to understand the client's digital landscape: domain, hosting, database, email, SSL certificate, CDN, and the existing systems the solution will be integrated with.

The subsequent layers address functionality, design, content, cost, and schedule. Each layer addresses a different question. Functionality describes what the user and administrator should be able to do. Design combines the interface, user experience, and brand identity. Content includes text, photos, graphics, videos, audio, translations, and the responsibility for their preparation. The budget and schedule indicate what can be implemented now, what needs to be scaled back, and what should be consciously moved to the next stage.

The concept of "highest standards" also needs to be broken down into specific requirements. The W3C develops many web standards, and WCAG defines testable accessibility criteria at levels A, AA, and AAA (W3C, "Accessibility Standards Overview"; W3C, "WCAG 2 Overview"). A "W3C compliant" field is not sufficient. The specification should indicate which standard we are using, what level of conformance we are adopting, and how we will verify it. Responsiveness, performance, security, backups, privacy, and acceptance criteria should be treated similarly.

A client might not realize that a contact form entails data obligations, post-submission messages, error handling, and proper footer links. They shouldn't discover these dependencies only after implementation. The role of the process is to connect the client's input with elements resulting from the solution's design and the agreed-upon standard.

A decision must be made after each layer, not just a memo.

A conversation without a summary quickly turns into a collection of miscellaneous memories. The client remembers one thing, the contractor another, and the AI ​​agent may receive a third interpretation. Therefore, a short document should be created for each area: a description of the findings, assumptions, open-ended decisions, and the implications for the cost and other parts of the project.

The client receives this document, provides comments, and confirms that they understand the expected result. This isn't about giving them a set of rules to click on. Acceptance should confirm a shared understanding: what will be done, what won't be done at this stage, what materials the client is expected to provide, and how both parties will recognize the correct result.

Early validation doesn't eliminate all errors, but it allows them to discover them while the change is still relatively inexpensive. The NASA Systems Engineering Handbook recommends validating expectations and requirements as early as possible and iteratively, because late detection of an incorrect solution leads to extensive rework (NASA, "Systems Engineering Handbook"). A small company's website isn't a spaceship, but the error mechanism remains familiar: the later we discover we've built the wrong thing, the more work must be discarded or redone.

The approved layers comprise the execution specification. This same specification serves to estimate work, time, and cost, and then becomes the context for the people or agents implementing the project. Instead of a general order to "make the website," the contractor receives agreed-upon goals, functions, content, appearance, constraints, standards, and acceptance criteria.

The most work can be done in what seems like a few clicks.

Budgeting is a difficult stage because the client sees only the final result. They might assume that a website is created from pre-made blocks and a few clicks. However, even the headline in the first section of the page requires a decision. It has to inspire trust, attract the right audience, explain the value of the offer, and fit the overall design. A sentence like "we're great" can be typed in a minute, but it usually doesn't give the recipient a reason to read further.

There are dozens of such seemingly small elements. Each can influence other parts of the site. Therefore, a reliable estimate isn't based on the number of subpages or blocks. It stems from the work needed to achieve the agreed-upon result, taking into account dependencies, and verifying that the whole thing actually works.

A good evaluation isn't meant to ensure that nothing in the project will ever change. It's meant to ensure that the change is conscious. If, after implementation begins, the client wants to add a store to a previously planned blog, it's not a minor tweak. It's a new stage with its own features, payments, orders, content, risks, costs, and timeline. They should undergo a separate interview, even if they use the same website and have the same relationship with the client.

Contractor objections can be part of good service.

Sometimes a client's requirement conflicts with their goals, budget, or good standards. In such cases, a contractor shouldn't hide behind the phrase "customer is king" or arbitrarily impose their own taste. A conversation is necessary, presenting both sides of the decision: what the client will gain, what they will give up, what risks they will accept, and which alternative better achieves their goals.

This is also an education. The client doesn't need to know the industry jargon, but they should understand what they're paying for and why the proposal is presented this way. Only then can they consciously approve a solution or accept the consequences of a different choice.

However, not every conflict can be resolved. I'd rather not start a project than take money for a website I know in advance won't serve the client. In the short term, this means losing the job. In the long term, it protects both parties from disappointment, conflict, and a project I wouldn't want to present as my own work.

Quality can foster trust, recommendations, and subsequent work, but it doesn't automatically guarantee anything. The market, visibility, offerings, and subsequent client activity still matter. That's why I don't want to sell a website as a magic customer acquisition machine. I can design a good tool and honestly explain how to use it. I can't promise a result independent of the entire enterprise.

Specification is the end of the interview and the beginning of accountability

The result of the process isn't a file with the client's answers. It's an approved implementation manual: a combination of the business goal, the needs of future users, the client's requirements, the contractor's expertise, standards, budget, schedule, and acceptance criteria.

Based on this, tasks can be initiated, progress reports can be reported, the project can be conducted, project acceptance can be conducted, the client can be trained, and support, updates, and backups can be scheduled. Without it, implementation is based on guesswork. With it, it can still be challenging, but at least we know what problem we're solving and who approved the method used to achieve the result.

The client should receive everything they specifically requested, as well as the elements necessary to ensure the entire system operates according to the agreed-upon standard. It's not about adding features they don't need. The point is to ensure that after completion, they don't discover they bought a piece of the system when no one told them about the other parts.

A website for the sake of having a website is pointless. A tool makes sense when its purpose, scope, and intended use are mutually understood before work begins. ## Bibliography

✦Building systems for greater autonomy.