Start with what the website needs to do
A website can introduce a service, help people compare options or make a first enquiry easier. Before deciding how many pages it needs, we define which of those jobs matters most. I also need to understand who will visit, what they already know about your business and what might stop them from getting in touch. That information guides the project from the beginning and gives us a shared basis for discussing each proposal.
If you already have a website, we can use it to identify what it explains well and what causes confusion. If you are starting from scratch, we work with the information you have: services, working methods, existing materials and common questions. You do not need to arrive with every decision made. It does help to separate what is essential for presenting the business from what could be added in a later phase.
A structure that helps people decide
Every page needs a purpose. The homepage gives visitors context, the service page explains the offer and the contact page shows how to take the next step. We can extend that structure when the content or the business need justifies it. Creating many similar pages does not replace a clear explanation. Each destination should offer something useful and be easy to recognise in the navigation.
I organise content around the questions a visitor may have: what you offer, who it is for, how it works and what they need to prepare. Headings and links help people follow that path without reading every word from start to finish. An invitation to get in touch makes more sense after enough information has been provided, and when it explains what happens next. That is how the page supports a decision.
Specific content, in your voice
Your website should describe your business accurately. Before writing commercial claims, we need to know which services you actually offer, what their conditions are and what you can demonstrate. The information you provide allows me to prepare or organise the text within the agreed scope. It also reveals gaps worth addressing before the design begins. Visual choices alone cannot make an unclear service easy to understand.
I aim for plain language, sections that make sense on their own and comfortable reading. The length depends on what needs explaining. One page may need examples, common questions or a detailed account of the process; another can meet the need with less text. Case studies, reviews and results should only be presented as genuine when the supporting information and necessary permissions are available. The content should give visitors sound reasons to trust what they read.
SEO-friendly, in plain language
Building an SEO foundation means helping search engines discover and interpret the content on your website. This affects page organisation, titles, descriptions, links and technical decisions. It also means using the language your audience uses and answering questions connected to your service. What the website promises should match what people find when they arrive. Useful content and a coherent structure give that work a practical purpose beyond individual settings.
This foundation is different from ongoing work on search visibility. A particular search position depends on factors beyond building the website, including competition and how Google responds to each query. I do not promise rankings or traffic. If your project needs keyword research supported by demand data, or monitoring after launch, we need to define those tasks and the available sources before including them in the work. Their scope should be clear from the outset.
Design for reading, browsing and getting in touch
Design gives content order and expresses the character of your business. Type, colour, spacing and visual hierarchy should make the main information easy to distinguish from supporting detail. Someone visiting on a phone should be able to understand the offer and find the contact information just as clearly as someone using a computer. The page needs to work with its content, including real headings and text lengths.
During the build, I review matters such as readability, contrast, links and keyboard use. Images and other resources that can affect loading are also considered. The aim is to balance visual expression with everyday usability. A formal accessibility audit, a specific integration or specialist requirements need to be defined within the scope, since different projects call for different checks. Agreeing on those needs early makes the review more useful.
Choose technology around how you will use it
The way a website is built depends on how you want to use it afterwards. If you need to publish regularly, an editing tool may be appropriate. If the content is stable, other approaches can be considered. Before choosing, we should know who will make changes, how often and how much independence they need. We also need to identify any tools the website will connect to and check whether those connections are feasible.
Bookings, a shop, a private area or a connection to an external system change the development and review work. I do not assume that undefined features are included. The proposal should describe what will be built, what relies on an external provider and which responsibilities remain after delivery. That allows you to assess the whole solution, including its ongoing needs, rather than making a decision based only on its first appearance.
Languages and content you can keep up to date
A multilingual website needs more than a language switcher. Each version should have reviewed content, consistent navigation and equivalent pages. We also need to decide how updates will be handled. If a service changes, the information in the other languages will need attention too. The number of languages and the responsibility for preparing translations should be clear before the work starts, along with who can check their accuracy.
The same approach applies to the future of the project. Before publishing, it helps to establish who controls the domain, hosting and necessary accounts, and how future changes will be handled. The initial build and any later support need clear boundaries. Discussing this from the start avoids unclear dependencies and helps us choose a way of working that fits your availability and the amount of day-to-day involvement you want.
A proposal you can understand and assess
To prepare a proposal, I need a description of the business, the purpose of the website and an idea of the pages, languages and features required. Existing materials or a current website can also help. With that context, we can define the scope and distinguish content, design and development work from any external costs or services. Open questions should be visible instead of hidden inside broad descriptions.
The first step is to tell me where you are now and what you would like the website to do. If some questions remain open, we identify them before turning them into commitments. A useful proposal should make it clear what is being considered, what still needs deciding and how decisions will be made. That is the starting point for creating a website that represents your business accurately and gives visitors the information they need.