Hiring a Web Designer for Your Restaurant: 9 Questions to Ask First

If you are wondering how to choose a web designer for your restaurant, start with these nine questions: ask for live restaurant sites they built, a written all-in price, a clear contract covering ownership and cancellation, and proof they understand menus, bookings, and mobile speed. The right designer answers all nine calmly and in writing — the wrong one dodges at least two of them.

Your website is the front door of your restaurant for everyone who has never walked past it. It answers the three questions every potential guest has — what do you serve, where are you, when are you open — and it either earns a booking or sends them to the place down the street. Yet most restaurant owners hire a web designer the way they would hire a plumber: a quick quote, a handshake, and a hope it works out. That is how restaurants end up paying thousands for a site they cannot update, a domain they do not own, and a designer who stopped answering emails in March.

This guide is written for independent restaurant, café, and bar owners in the Nordics and beyond who are about to hire a web designer — or wondering whether the one they have is the right one. It walks through the nine questions that separate professionals from pretenders, with real 2026 price estimates, contract guidance, Nordic-specific notes on VAT and market rates, and an honest comparison of freelancers, agencies, and subscription services. No sales pitch for any particular vendor — just the questions, and what good answers sound like.

1. Can you show me restaurant websites you've built?

This is the first question for a reason: it filters out most of the wrong candidates in under a minute. A designer who has actually built restaurant websites will send you links immediately. A designer who has not will send you excuses, mockups, or "concept designs" — none of which prove they can ship a working site that takes bookings on a Friday night.

Live sites, not mockups

Insist on live, working websites you can open right now. Mockups and Figma screenshots are easy; a launched site that a real restaurant depends on is the actual evidence. Open at least three of them and do the customer's job: find the menu, check Friday's opening hours, and try to make a booking — all on your phone. If you struggle, their future customers will too, and that is a verdict on the designer's work, not on you.

What restaurant-specific quality looks like

Restaurant websites fail in predictable ways, so you know exactly what to check for in a portfolio:

• The menu is real text, not a PDF. PDF menus are unreadable on phones and invisible to Google. If a designer's portfolio sites still use PDF menus, they are not keeping up.
• Booking takes three taps or fewer. Open the site, find the booking button, reach a working booking form. Every extra step loses guests.
• Hours and address are obvious on mobile. If you have to hunt for them, the designer does not understand restaurant customers.
• The site loads fast on a phone. It should feel instant on 4G. Bloated image sliders and auto-playing video backgrounds are a bad sign.
• The food photography is real. Stock photos of generic pasta on a designer's restaurant site suggest the restaurants never cared enough to supply real photos — or the designer never asked.

Watch for template repetition

Open five portfolio sites side by side. If they all look like the same template with different logos — same layout, same stock-style hero image, same "Welcome to our restaurant" headline — you are not hiring a designer, you are renting a template with a markup. That is not automatically a dealbreaker (templates can be fine for tight budgets), but you should know what you are buying and pay template prices, not custom-design prices. A designer worth custom rates shows you sites that look like different restaurants, because they started from each restaurant's identity, not from a theme.

2. What will the website really cost — all in?

Ask for the all-in number, not the build quote. A suspiciously cheap quote usually means the extras are hiding somewhere: the domain, the hosting, the booking system licence, the photography, the translations, the "small changes" billed at €90 an hour. As 2026 estimates, here is what restaurant websites typically cost across the common build types:

For a deeper breakdown of what drives these numbers — page count, ordering systems, photography, and the three-year total cost of ownership — see our 2026 restaurant website cost guide, which walks through pricing, content, and ordering options in detail.

The extras nobody puts in the quote

When a designer says "$2,000 for the website", ask what is not in that number. The usual suspects: domain registration (~$15/year, trivial but revealing — see question 7), hosting ($10–$50/month), SSL certificate (often free now, but some hosts still charge), the booking system's monthly licence ($30–$150/month depending on the platform), professional food photography ($200–$600 for a shoot in the Nordics), copywriting, and translations. In bilingual markets like Finland and Sweden, a second language version can add 20–40% to the content work — worth asking about upfront rather than discovering mid-project.

Nordic rates and the VAT question

In the Nordics, expect rates at the higher end of the international bands: a typical Finnish freelancer charges roughly €1,500–€4,000 for a complete restaurant site, and agencies in Helsinki, Stockholm, or Oslo rarely start below €4,000–€5,000 for custom work. One practical trap for first-time buyers: quotes to businesses are usually shown without VAT — 25.5% in Finland, 25% in Sweden and Norway. A "€3,000" quote is really €3,765 out of your account in Finland. Always ask whether a price includes VAT (in Finnish quotes, look for "sis. alv" vs "alv 0%").

3. Freelancer, agency, or subscription: which fits a restaurant?

There are three ways to get a restaurant website built, and the right choice depends on your budget, your appetite for project management, and how much ongoing help you want. Here is the honest comparison — including the subscription model that most "freelancer vs agency" articles conveniently leave out:

When a freelancer wins

If your needs are straightforward — a beautiful site, a readable menu, online booking via an external system, maybe two languages — a good freelancer is the best value in the market. You talk directly to the person doing the work, decisions are fast, and there is no agency overhead in the price. The risk is concentration: if they get sick, overbooked, or simply move on, your site's future walks out with them. Mitigate it with a contract that guarantees you own everything (question 5) and documentation of how the site is built.

When an agency wins

Agencies earn their premium on complex projects: multi-location groups, custom online ordering, deep integrations with POS or loyalty systems, or a full rebrand alongside the site. You get a team — designer, developer, project manager — and a process with milestones and accountability. The trade-off is cost and attention: a €4,000 project at a €10,000-minimum agency makes you the smallest client in the building. Ask who exactly will work on your site and how many restaurant projects they run at once.

When a subscription wins

The subscription model flips the economics: instead of paying thousands upfront and then hunting for someone to maintain the site, the provider builds it for free and bundles design, hosting, security, updates, and support into one monthly fee. For a busy owner who never wants to think about the website again, that is often the rational choice — the provider only keeps your business if the site keeps working. Providers who build restaurant sites this way, like PowerfulWebsite, live or die on retention, which aligns their incentives with yours. The honest caveat: you are renting, not buying, so read the exit terms (question 7) before you sign — a cheap monthly fee with a punishing cancellation clause is not a bargain.

4. What features will my restaurant website include?

A designer who starts by showing you design styles before asking about features is decorating, not problem-solving. The features are the product; the design is the wrapping. Before any contract, agree in writing on exactly what the site will do — because "a restaurant website" means wildly different things to different designers.

The non-negotiables

Every restaurant website in 2026 needs these, regardless of budget:

• Menu as real, readable text — with prices, updated easily, readable on a phone without pinching or zooming.
• Opening hours that are always current — including holiday exceptions, ideally manageable by you in under a minute.
• Address with map and tap-to-call phone number — above the fold on mobile, not buried on a contact page.
• Online booking — either integrated or a prominent link to your booking system; "call us to reserve" alone costs you the under-35s.
• Mobile-first, fast loading — the majority of your visitors are on phones, often on the street nearby. If it is slow, they leave.
• Google-friendly basics — proper page titles, one page per topic, structured data for opening hours and location so search results show the right information.

The worth-paying-for extras

Beyond the basics, the features that actually move revenue for restaurants: online ordering for pickup or delivery (commission-free beats marketplace commissions fast), a second language version (in the Nordics, Finnish/Swedish or English doubles your addressable search traffic), gift card sales, a newsletter signup for slow Tuesdays, and photo galleries you can update yourself when the menu changes. If your designer cannot clearly explain which of these you need and which you do not, they are selling packages, not advice. Speed deserves special attention — run any designer's portfolio sites through a speed test before hiring them, using the method in our 30-minute restaurant website speed guide.

What to skip (for now)

Be wary of feature lists padded with things that sound impressive and do nothing: elaborate animations, auto-playing video backgrounds (slow, annoying, expensive), a blog nobody will update, complex loyalty systems for a 40-seat restaurant, or an app nobody will download. Every feature has a maintenance cost forever — ask "who updates this, and what happens when we stop?" If the answer is vague, cut it from the scope and the price.

5. What does the contract cover?

A professional designer offers a written contract without being asked. If you have to ask twice, that is already your answer about how the project will go. The contract does not need to be long — two clear pages beat ten vague ones — but it must nail down the following:

• Exact scope: which pages, which features, how many languages, how many design revision rounds. "Website for restaurant" is not a scope; a page-by-page list is.
• Total price and payment schedule: a fixed total beats hourly billing for standard restaurant sites. Typical structure: 30–50% upfront, the rest on milestones or launch. Never pay 100% before launch.
• Timeline with milestones: start date, content deadline (yours), design draft date, launch date — and what happens when either side misses a date.
• Ownership: who owns the domain, the design files, the content, and the site itself — during and after the project (more in question 7).
• Cancellation terms: what happens if either side walks away mid-project, and what it costs. You want the right to take everything paid for so far and leave.
• Maintenance and support: what is included after launch, for how long, response times for fixes, and what counts as billable extra work.
• GDPR and legal basics: in the EU, the site needs a privacy notice, cookie consent for analytics, and a data-processing arrangement if the designer handles customer data (e.g. booking forms). Ask who is responsible for setting this up.

The 8-point contract checklist

Before signing, confirm these eight points in writing — one email prevents most disputes:

1. Page-by-page scope with features and languages.
2. Fixed total price with payment milestones — never 100% upfront.
3. Timeline with dates for both sides.
4. Domain registered in your name.
5. You own the site files and content.
6. Exit terms — what you keep and what it costs to leave.
7. Maintenance: what's included, response times, hourly rate for extras.
8. GDPR setup responsibility.

6. What are the red flags?

Good designers share patterns; bad ones do too. Walk away — politely, quickly — when you see these:

• No live restaurant sites to show. The portfolio is all mockups, "coming soon", or sites for completely different industries. Restaurant websites have specific demands; generalists learn on your money.
• No written contract. "We don't really do contracts, we're easy to work with" is how disputes start. Professionals put it in writing precisely because they are easy to work with.
• The domain gets registered in their name. This is the classic hostage situation: leaving means losing your web address. Your domain, your name, always.
• Opaque bundled pricing. One monthly fee with no breakdown of what it covers, or a build quote that cannot itemise design vs content vs integrations. If they cannot explain the price, they cannot defend it later either.
• Pressure tactics. "This discount expires today", "I can only hold your slot until Friday". Real demand does not need countdown timers.
• They badmouth the technology question. Ask what platform the site is built on and why. "Don't worry about the technical stuff" from a technical vendor is a red flag, not reassurance. You need to know enough to leave one day.
• Reviews that don't exist. No Google reviews, no testimonials with real names and businesses, no references you can call. In 2026, a working designer leaves a trace.
• Everything is "easy" and "no problem". Experienced designers tell you what is hard: the menu migration, the bilingual content, the booking integration. Someone who has never hit a problem has never shipped.

7. Who owns the domain, the site, and the hosting?

This is the least glamorous question and the most important one. Ownership disputes are the number-one source of restaurant-website horror stories: the owner who discovers the "web guy" registered the domain in his own name, the restaurant that cannot leave its provider without rebuilding from scratch, the menu updates held hostage over an unpaid invoice dispute. Get every answer in writing before the project starts.

The domain must be in your name

Your domain — yourrestaurant.com — is a business asset, potentially worth years of Google rankings and printed-on-everything branding. It must be registered with you as the registrant, on an account you control, with an email address you control. If the designer "handles it for you", make sure "handling" means registering it in your name on your account — not theirs. This single check prevents the most common hostage situation in the industry. Our guide to choosing a domain name for your restaurant covers registration, renewals, and the mistakes to avoid.

The site files and the content

Ask plainly: "If we part ways in two years, what exactly do I get, in what format, and what does it cost?" Good answers sound like: "You get the full site files, the database, and all content — it's yours, you paid for it." Bad answers sound like: "Well, the site stays on our platform" (translation: you rent it and leaving means starting over) or "We can discuss that if it comes up" (translation: it will cost you). Neither is automatically disqualifying — subscription models legitimately bundle hosting — but you must know which deal you are signing.

Hosting and access

Find out where the site lives, who pays the hosting bill, and whether you have admin access. At minimum, you should hold (or be able to get within 24 hours): domain registrar login, hosting access, and full admin access to the site itself. A designer who insists only they can touch anything is selling dependence, not service. Professionals give you the keys and earn your continued business by being useful, not by being the only one with the keys.

8. What does maintenance cost, and who does the updates?

A restaurant website is not a brochure you print once — it is a living thing. Menus change, hours change for holidays, photos go stale, software needs security updates. The question is not whether the site needs maintenance, but who does it and what it costs. As a 2026 estimate, ongoing maintenance typically runs $50–$200+/month depending on what is included.

What maintenance should include

A proper maintenance arrangement covers: software and security updates, daily backups with a tested restore process, uptime monitoring, small content changes (menu prices, opening hours) with a defined turnaround, and a clear hourly rate for bigger work. Ask for response times in writing — "we'll get to it when we can" is not a service level. Also ask what happens if the site gets hacked or goes down on a Saturday night: who notices, who fixes it, and how fast.

Can you update it yourself?

You should be able to change a menu price or update holiday hours yourself in a few minutes, without calling anyone. Ask for a demo of the content editing before you sign — if updating the menu requires the designer, every seasonal change becomes a billable ticket and a waiting period. The best setups give you simple self-service for daily content and professional cover for everything technical. And keep the site fast over time: images uploaded straight from a phone can quietly bloat a site until mobile visitors bounce — the checks in our 2026 mobile optimisation checklist take under an hour and prevent most of the rot.

The real cost of "free" maintenance

Some designers bundle "free updates forever" into the build price. Read that as: updates are priced into the build, prioritised behind paying work, and increasingly resented over time. Maintenance has a real cost — server time, update labour, someone answering your email. A transparent monthly fee with defined scope beats a vague promise every time. When comparing offers, add three years of maintenance to the build price; that total is the number you are actually deciding on.

9. How long will it take — and do I need someone local?

Two questions for the price of one, because they share an answer: what actually determines the outcome is not geography or speed promises, but preparation and communication.

Realistic timelines

As a rule of thumb: a simple restaurant website takes 4–8 weeks from kickoff to launch; a custom or multi-location project takes 2–4 months. Be suspicious of anyone promising a custom site in a week (corners are being cut somewhere) and of anyone who cannot give you a date at all. And know this uncomfortable truth: most delays come from the restaurant, not the designer. The three classic stall points are menu content that never arrives in final form, photography that keeps getting postponed, and approval rounds where three partners disagree for a fortnight. Designers who have done this before will tell you what they need from you and by when — one of the quiet signs of a professional is a client checklist, not just a project plan.

What the designer needs from you

Before kickoff, have ready: final menu text with prices (as text, not a PDF), your logo in high resolution, 10–20 good photos of the food and the room (or a scheduled photo shoot), your opening hours including holiday exceptions, and one decision-maker authorised to approve things. Every missing item adds roughly a week. The fastest projects are the ones where the restaurant does its homework first.

Local vs remote

You do not need a designer in your city. A remote designer — even in another country — can build an excellent restaurant website provided communication is smooth and they understand your market. In the Nordics that means: local language support, local payment methods, GDPR compliance, and an understanding of how people here actually find restaurants (Google Maps first, Instagram second). What matters far more than location is restaurant experience: a designer who has built sites for restaurants understands menus, opening hours, booking flows, and food photography in a way a generalist never will. The one genuine advantage of local is physical: they can visit, photograph, and eat at your restaurant. That is nice — but it is rarely worth paying double for, and a great remote specialist beats a mediocre local generalist every time.

The pattern is consistent: the fastest website projects are not the ones with the fastest designers — they are the ones where the restaurant delivered the menu text, the photos, and the decisions on time. Do your homework first, and the timeline takes care of itself.

Frequently asked questions