How to choose a web design company.

Decide what the website has to do first

Most poor hires begin before the first meeting. A business asks several web design companies for a website, receives proposals that describe different things, and compares them as if they were the same. They are not. One covers design only. Another includes texts, hosting and care after launch. A third is a ready-made theme with your logo on it. Without a shared description of the job, the comparison is guesswork.

So the first step is yours. Write down what the website has to do for the business: bring in enquiries, sell products, take bookings, explain a service to a particular kind of client, support a sales team. Write down who will use it and what they must be able to do on a phone. Write down what exists already: a domain, an old site, a logo, photographs, texts. The brief at the end of this guide gives you a structure. Send the same brief to every studio you approach. The proposals then become comparable, and the way each studio responds to the brief already tells you a good deal.

Keep one idea in mind throughout. You are not only choosing a design. You are choosing who will be responsible for a piece of software your business depends on, for as long as it runs. Every point in this checklist follows from that, and every point applies whichever company you end up hiring.

Questions to ask before you hire

A first call should leave you knowing how a studio works, not only what it has made. These questions are worth putting to every candidate, and the answers are worth writing down.

Who will do the work? Ask who designs, who builds, and who you will speak to week by week. If parts are subcontracted, that is not a problem in itself. You should know, and the studio that signs should remain responsible for the result.

What do you need from us? A good partner will say plainly what it expects: texts, photographs, decisions, access to existing accounts, one person who can approve work. Most delays in a web project start on this list, not on the studio's side.

How do you handle changes to the scope? Every project changes along the way. Ask how a new request is assessed, how it is priced, and whether it is agreed in writing before the work is done.

How do you test before launch? Ask which devices and browsers are checked, who tests the forms, and whether the site is reviewed at a staging address before it goes live.

What happens when something breaks? Ask who answers, through which channel, and how soon the first response comes. Ask whether this is covered by an agreement or offered as a favour.

Can we speak to one of your clients? A reference from a business that has worked with the studio for some time is worth more than any testimonial on the studio's own website.

Notice, too, what the studio asks you. A partner who asks nothing about your customers, your sales process or who will keep the content current is preparing to sell you a design, not to solve a problem.

How to read a portfolio

A portfolio shows what a studio wants to be judged on. Read it carefully, then test it.

The first test is simple: is the work live? A screenshot proves that a design existed. A working website proves that it was built, launched and kept running. Open each project on your own phone. See how quickly it loads, whether the text is readable, whether the menu works with a thumb, whether the forms submit. A portfolio made mostly of mock-ups, unbuilt concepts or sites that no longer exist tells you less than it appears to.

The second test is scope. A project page that says a studio worked on a brand does not say what it did. For each project you like, ask: did you design it, build it, write it, or all three? Who maintains it now? Can the client still change it without you? A studio that made the logo and handed over to another developer may still show the whole site. That is not necessarily dishonest, but you need the precise answer.

The third test is fit. Look for work that solved a problem close to yours: a service business that takes enquiries, a shop with a real catalogue, a product with signed-in users. Visual style matters less than it seems, because a capable designer works in many registers. What is hard to fake is experience with the kind of functionality your business needs.

Apply the same tests to us. Our work page lists three products, all of them live: Leadinsure, the website of an insurance brokerage at leadinsure.gr, with quote requests for individuals and businesses, a partner area and a library of guides; Kalimenu, at kalimenu.gr, a QR menu in eight languages with ordering and payment from the table, waiter call and separate kitchen and bar screens; and AppInsure, a free iOS app with its website at appinsure.gr, which gathers a person's insurance policies in one place and is kept current by their broker. The same page states what we did on each: web design, development and SEO setup for Leadinsure; product design, web design and development for Kalimenu; the iOS app, web design and development for AppInsure. Open the two websites on your phone and look the app up on the App Store before you read anything we say about them.

Who owns the code, the domain and the accounts

This is the part of an agreement most owners skip and later regret. A website is not one thing. It is a domain, a hosting account, a codebase, a content management system, design files, fonts and images under licence, an email service, an analytics account and a Search Console property. Each one is registered to someone. If it is registered to the studio, you need the studio to reach it.

The rule is plain. Anything that identifies your business should be registered to your business, with an email address you control as the owner, and the studio added as a user. That applies first to the domain. It applies equally to analytics, Search Console, your Google Business Profile and any payment provider. Where a studio must hold an account for technical reasons, the agreement should say so and describe how it is transferred.

For the code and the design, ask what you receive at the end and in what form: the source code, access to the repository, the design files, written notes on how the site is deployed and updated. Ask which licences the site depends on and in whose name they are held. Ask what happens if you decide to part ways. The answer should describe a handover, not a negotiation.

A studio may reasonably keep its own tools, internal libraries and methods. That is normal. What should not happen is a website that cannot run, or cannot be edited, without the studio's permission. If a closed platform is involved, ask whether you can export your content and move it elsewhere, and ask to see how.

What a written proposal must contain

A proposal is the document you return to when there is a disagreement. It should be specific enough to settle one. At a minimum it should state the following.

Scope. The pages, templates and functions included, described in plain language, and what is excluded. Exclusions are the most useful lines in any proposal, because that is where surprises come from.

Deliverables. What you receive: the live site, the source, the design files, the documentation, the accounts. If training is included, for whom and how much.

Responsibilities. Who writes the texts, who supplies photographs, who moves content from an old site, who sets up redirects, who approves each stage.

Stages and timeline. The order of the work, what is approved at each stage, and a timeline that shows what depends on you. A date with no dependencies is a guess.

Price and payment terms. A total for the agreed scope, how it is split across stages, and how work outside the scope is priced. A price only means something next to the scope it buys.

Launch and after. What is checked before launch, what warranty period follows, what ongoing care is offered, on what terms, and how you leave it.

If a proposal leaves any of these out, ask for it in writing. A studio reluctant to commit to scope on paper is likely to stay reluctant later. Launch checks deserve detail of their own: our technical SEO checklist for a new website lists what should be verified on the live domain before anyone announces it.

What happens after launch

Launch is the start of a website's working life, not the end of a project. From that day the platform needs updates, the certificate and the domain need renewing, the forms must keep delivering, and backups must exist and restore. Search engines begin to read the site, and problems found in the first weeks are the cheapest to fix.

Ask every candidate what happens on the day after launch. Who updates the platform and its components? Who checks that the contact form still sends? Where are the backups kept, and when was a restore last tested? How soon does a first response come when something fails, and what does it cover? Is there a written report, and what is in it?

Some studios offer this under a maintenance agreement. Others hand the site over and expect your team, or another provider, to take it on. Both can work. What does not work is silence on the subject. If you plan to look after the site yourself, ask for documentation and training as part of the handover. If you want the studio to keep it, ask for the terms in writing. Our guide to what a website maintenance plan should include sets out the parts to look for, whoever provides them.

One more question is worth asking. What became of the studio's websites a few years after launch? Who answered when something broke? Could the client change things without starting again? The answers say more about a partner than any case study.

Red flags

None of these proves on its own that a studio is a poor choice. Each is a reason to slow down and ask more.

A price with no scope. A figure sent after a short call, before anyone has asked what the site must do, is a price for something. You do not yet know what. Later it will be revised, usually upwards, or the scope will shrink to fit it.

Lock-in. The domain registered in the studio's name. A platform you cannot export from. Source code that is never handed over. Hosting only the studio can provide. Any one of these makes leaving expensive, and a partner you cannot leave has little reason to serve you well.

No maintenance plan. A proposal that ends at launch, with no mention of updates, backups or support, leaves the most expensive problems to chance. So does a maintenance offer described in a single line.

Guaranteed rankings. No one controls search engines. A studio can build a site that is technically sound and easy to find. It cannot promise a position.

A portfolio you cannot visit. Screenshots only, with no live addresses, or addresses that no longer open.

Pressure to sign. A discount that expires this week. A start date that must be confirmed today. Good studios are usually busy enough to let you think.

No questions about your business. If the conversation is only about colours and pages, the result will be a set of pages.

A brief you can copy

Send this to every studio you are considering. Fill in what you know and mark what you do not. A good partner will help you complete the rest, and how each one does it is part of your decision. You can send it to us through the contact page, or to anyone else.

The business: what you do, for whom, and where your customers come from today.

The purpose: what the website must achieve, in order of importance.

The audience: who will visit, what they need to find, and in which languages.

The actions: what a visitor must be able to do: call, send an enquiry, book, buy, sign in.

What exists: domain, current website, logo and brand guidelines, texts, photographs, accounts, and who holds the access to each.

Content: who will write and supply texts and images, and who will keep them current after launch.

Connections: systems the site must work with, such as a booking tool, a shop, a CRM, a payment provider or an invoicing service.

Examples: a few websites you find clear, and what exactly you like about each.

Constraints: a date that matters, a budget range if you have one, and who approves the work.

After launch: whether you want the studio to maintain the site or to hand it over to your team.