How do you choose a website developer?

By checks rather than screenshots: the domain, hosting and code must be yours; their past sites should pass Core Web Vitals on a phone; SEO basics should be part of the build; you should be able to edit content without them; and support after launch should be in the contract with a response time.

Who should own the website's domain?

You or your company. ICANN defines the registrant as the domain name holder, who assumes sole responsibility for the registration and must keep its information accurate and current. Register the domain in your own name and on your own email, and give the developer access.

What are Core Web Vitals?

Google's three Core Web Vitals, which measure real-world user experience: LCP (loading, good within 2.5 seconds), INP (responsiveness, 200 milliseconds or less) and CLS (visual stability, 0.1 or less), measured at the 75th percentile of page loads.

Template or custom website?

A template launches faster and costs less and is often enough for a small, standard job. A custom site is worth it when the brand has its own visual language, needs a specific function or connects to several systems. The ownership, speed and support checks apply to both.

How to choose a website developer

A website developer is the person or team who builds a site, publishes it and then keeps it alive. How to choose a website developer? People often go by portfolio screenshots, and a screenshot shows the design, not what sits underneath it: speed on a phone, who owns the domain, whether you can change a text without the developer, and what happens a year after launch.

Below are the checks worth making before you sign. Some are questions for the meeting; some are tests you can run yourself in ten minutes.

First decide what the site is for

Before choosing a developer, write one page: what a visitor should do on the site (call, fill in a form, buy, find information), how many languages it will have, who will change texts and photos, and which systems it has to connect to: a CRM, payments, bookings. Without that page you cannot compare proposals, because each one is pricing a different site.

Read the portfolio as live sites, not pictures

Ask for links, not a presentation. Open two or three of the sites on your own phone, on mobile data rather than office Wi-Fi. Switch the language if the site has two. Ask the developer to demonstrate form delivery in a test environment. Check whether content is current, then ask who is responsible for updates and what ongoing support was agreed. Ten minutes of this tells you more than an hour of slides.

Who owns the domain, the hosting and the code

This is the first question, and the easiest one to skip. ICANN defines the registrant as the individual or entity who registers a domain name, also known as the domain name holder. ICANN also states that the registrant assumes sole responsibility for the registration and use of the domain, and must keep the registration information accurate and up to date. So the domain should be registered in your name or your company's, on your email address, not the developer's.

The same goes for the hosting account, administrator access and the source code. Write into the contract that all of it is yours from launch day, with the developer holding access. If the relationship ends, the site stays with you, not with them.

Speed, and the phone

Google assesses a site through its mobile version. According to Google Search Central, it uses the mobile version of a site's content, crawled with the smartphone agent, for indexing and ranking. Keep the primary content available to Googlebot on the mobile version, even if its layout differs from desktop.

For how a page loads and behaves, Google has three measures, the Core Web Vitals. LCP (how fast the main content loads) is good within 2.5 seconds; INP (how fast the page responds to an action) at 200 milliseconds or less; CLS (how much the page jumps while loading) at 0.1 or less. The thresholds are measured at the 75th percentile of page loads. Ask the developer to run two or three sites they built through PageSpeed Insights, or run them yourself. It takes less than ten minutes.

SEO basics go in during the build, not after

Google's own advice on hiring an SEO is direct: a good time is when you are planning a redesign or a new site, the earlier the better, so the site is search-friendly from the bottom up. In practice that means a title and description for each page, a logical heading structure, readable URLs, hreflang and properly linked language versions for a bilingual site, and descriptions (alt text) on images. If this work is deferred, clarify who will do it and whether changes to the build will add cost. We write about the specifics of SEO in Georgian separately.

Accessibility

An accessible site is often easier for everyone: people whose eyesight is failing, people who use only a keyboard, people reading on a phone in the sun. The current W3C Recommendation for web accessibility is WCAG 2.2, which W3C advises using so that accessibility work stays applicable in the future. In the meeting, ask how they check text contrast, provide text alternatives for informative images, handle decorative images and test forms using a keyboard alone.

Who changes the text tomorrow

A site does not end on launch day. Prices change, a new service is added, photos age. Ask how you will change a text or an image yourself, without writing to the developer, and ask to see it in a test environment rather than hearing a promise. If every small edit needs the developer, agree on the turnaround time and any charges before signing.

Analytics and the form: test them before launch

Agree who installs analytics, which actions it counts as results (a form sent, a call button tapped, a purchase), and how the cookie consent banner works with it. Then test it: send the form, check that the message arrives at the right address and that the analytics recorded it. A site that launches without this has no memory of its first months, and those are exactly the months you will want to compare against later. It is also where a first marketing audit starts.

Support after launch

Agree who updates the system and its plugins, how often backups are made and where they are kept, who responds if the site goes down at night, and within what time. All of it in the contract, with a price or an hourly rate. "We will always help" is not a response time.

The price, line by line

Ask for the price broken into lines: design, development, copy, photography, translation, licenses, and the costs that come back every year, such as hosting, the domain renewal and paid plugins. A proposal that looks cheaper may have moved one of those lines to you without saying so. Two proposals can only be compared when the lines are the same.

Template or custom site

Both have their place. A site built on a template launches faster and costs less, and for a small, standard job it is often entirely enough. A custom site is worth it when the brand has its own visual language, when you need a specific function, or when the site connects to several systems. In both cases the checks above apply in the same way.