How to Choose a Website Developer and Not Pay for the Same Site Twice

You search for “website design services” and get hundreds of identical promises: “turnkey”, “fast”, “SEO included”, “affordable”. Everyone has beautiful mockups and a “personal approach”. These pages are written to make you call, so comparing them with each other is pointless.

Choosing a developer usually goes wrong because of things that looked like details at the start: the domain was registered to the studio, the freelancer bought hosting with his own card, the contract says “website development” without any list of work, and the whole fee was paid upfront in one go. While everything is fine, none of this shows. It shows when something goes wrong.

To keep this concrete, let’s take a made-up example and carry it through the whole article: a distributor of warehouse racking that sells B2B and wants a catalogue of several hundred items, a request for quote form and a load calculator. The company is invented, the situations are typical.

The most common mistake happens before the first call: the owner goes to developers without knowing what they’re buying. Then one quotes a five page site, another an online shop with payments, a third a platform with customer accounts, and there is no way to compare those numbers.

Before searching, our distributor should write down at least this:

• why the site exists: quote requests, finding dealers, supporting the sales team;
• who comes and what they’re looking for: a warehouse purchasing manager, the owner of a logistics company, an engineer calculating loads;
• how many pages and products at launch, and where descriptions, photos and specifications will come from;
• which integrations are needed: CRM, accounting or ERP system, analytics;
• who will add content to the site after launch;
• which languages are needed and whether other markets are planned.

A page or two of plain text is enough for this; the detailed specification can come later. How to write it so that every developer understands you the same way is covered in the article “Website brief template”. With a brief in hand, quotes become comparable, and the conversation is about your business from the first minute.

You have four basic options, and none of them is better by default. The question is what fits your specific task and how much of the process you’re willing to manage.

For our distributor, with a catalogue, a calculator and an accounting integration, a solo freelancer is already risky: one person has to be the designer, the developer and the tester. A site builder will handle a promo page, but a catalogue of hundreds of items with a calculator will hit its limits. The realistic choice is a studio or an agency, and the difference between them comes down to whether you need SEO and ads right away.

What the price is made of

There won’t be any prices here: without a brief, any number is made up. But here is what you pay for, and these items are exactly what explains the difference between quotes:

• analysis and structure: which pages are needed and how a visitor moves from them to an enquiry;
• design: a ready template, an adapted template or a custom design for your brand;
• development: front end, admin panel, catalogue, filters, calculators, forms;
• integrations: CRM, accounting, payments, delivery, analytics and ad pixels;
• content: copy, photos, product import, translations;
• technical groundwork for search: speed, mobile version, structured data, redirects from the old site;
• testing and launch: checks on different devices, hosting and email setup;
• support after launch: updates, backups, small edits.

When one quote is several times cheaper than the others, most often part of this list is simply missing from it. Ask directly which items are included. What our development includes and what the price depends on is described on the websites and online shops service page.

A portfolio on a contractor’s website is a shop window. The images are selected, cropped and shown from their best angle. So don’t look at the images, look at the live sites behind them.

Is the site still alive?

Ask for a list of links to real projects. Open each one. If half the links lead nowhere, to a domain for sale or to a completely different site, that’s an answer too: either the clients left and rebuilt, or the projects never made it to launch.

You can see a page’s history in the Wayback Machine: enter the address and look at snapshots from different years. Domain data can be checked through WHOIS: for .ua domains there is Hostmaster, for .de domains DENIC, for international zones such as .com ICANN Lookup. Hostmaster and ICANN Lookup show the registration date and the registrar; DENIC shows less, usually the status, the name servers and the date of the last change. The owner’s personal data is often hidden, so WHOIS won’t tell you who the domain is registered to, but it will hint at how old the site is.

Speed in PageSpeed Insights

Open PageSpeed Insights, paste the address of a portfolio site and look at the mobile tab. There are two blocks there, and people often mix them up:

• real user data from the Chrome User Experience Report for the last 28 days. If there isn’t enough data for the page, the tool shows data for the whole site, and if there isn’t enough of that either, the block is empty (PageSpeed Insights, about the report);
• the lab test by Lighthouse: one simulated load on a mid range phone. A score of 90 or higher is considered good, 50-89 needs improvement, below 50 is poor.

For the core metrics, Google considers these values good: the largest element on the page (LCP) appears within 2.5 seconds, the response to interactions (INP) is within 200 milliseconds, layout shift (CLS) is within 0.1. Don’t expect a perfect 100: the test fluctuates, and the client may have loaded the site with widgets after handover. But if all of a contractor’s live sites are consistently in the red zone on mobile, speed simply isn’t part of their idea of “done”. What these metrics mean and what you can do about them without a developer is covered in a separate article on Core Web Vitals without a developer.

Mobile version

Google indexes and ranks sites based on their mobile version (Google Search Central, mobile-first indexing). Google’s separate tool for checking whether a site is “mobile friendly” was retired back on 1 December 2023, together with the report in Search Console, and Google recommended Lighthouse and other tools instead (Google Search Central Blog, 2023). So if a contractor still shows you the “green tick” from that test, the argument is out of date.

A check that works better than any test: open three or four portfolio sites on your own phone over mobile data and walk the customer’s path. Find a product or a service, open the menu, fill in a form. What to look at:

• whether the text is readable without pinching to zoom;
• whether the buttons are spaced apart and easy to hit;
• whether the menu opens and closes without surprises;
• whether the page jumps around while it loads;
• whether the form is comfortable on a phone and the right keyboard opens for the phone number and email fields.

For our distributor it’s especially important to look at the catalogues in the portfolio: whether the filters work on a phone and whether the specification tables spill over the edge of the screen.

What to ask about each project

For two or three projects, ask: what exactly this team did (the whole site or only the design), how long the work took, and whether they still support the site. If possible, ask for the client’s contact. A refusal with an explanation is fine; “why would you need that” is already a signal.

The first meeting tests whether the contractor understands your task and is willing to talk about the uncomfortable parts. Here are the questions worth asking:

1. Who exactly will work on the project? Names and roles: designer, developer, manager. Whether any of the work will be subcontracted.
2. What do you want to know about my business? A good contractor asks questions on their own: about customers, sales, competitors. If there are no questions, you’re being sold a template.
3. What do the stages look like, and what do I see after each one? A prototype, the design, a test version at a separate address.
4. Which platform will the site run on, and why that one? Whether another developer will be able to work with this code later.
5. Who will the domain and hosting be registered to? The right answer: to you, with your email and your payment method.
6. What happens to the code after handover? Whether you’ll get a full copy of the files and the database.
7. Who adds the content, and who moves the old pages? For our distributor, who already has an old site, this is also a question of redirects: without them you can lose search traffic, so ask how the contractor plans to move the old addresses.
8. What does the warranty cover, and what happens after it ends? The period, which bugs are fixed for free, how much ongoing support costs.
9. How and how quickly do we communicate? The channel, response time, how often you get reports.

What matters is not only what they answer, but how: specifically, or “don’t worry, we’ll take care of everything”.

Some problems are visible as early as the proposal stage. Here are the signals that should make you stop and ask more questions:

• An exact price for a complex project without a brief. You got a figure for a catalogue with integrations after two sentences in a messenger. That means they priced an average project on the market, not yours. The difference will show up later as “extra charges for additional work”. A fixed price for a package with a scope described in advance (for example, a business card site with a list of pages) is a different story: there you can see what’s included.
• “We’ll build the whole site in three days.” A mockup or a homepage prototype in a few days is normal. But a catalogue of hundreds of items, a calculator, an accounting integration and testing on phones don’t fit into three days. Most likely you’ll get a ready template that someone calls a website.
• The domain in the developer’s name. “We’ll register everything ourselves, you don’t need to deal with it.” Convenient while you get along. When you stop getting along, your site’s address stays in someone else’s hands.
• Full payment upfront. Paying everything in advance takes away your only lever when something goes wrong.
• No live sites in the portfolio. Only images and “projects under NDA”.
• No contract, or a one page contract that says “website development as agreed”.
• Guaranteed results. “First page of Google in a month” or “a hundred leads a week”. Nobody can honestly promise that, because the result depends on the market, the competitors and what happens after launch.

One flag isn’t a verdict, but three at once is a good reason to look at other candidates.

The contract is signed, the work is under way. There can be warning signs here too, and it’s better to notice them in week two than in month four.

1. Deadlines slip, and you’re the last to know

A delay on its own isn’t a disaster: in a real project something always goes off plan. What matters is how you’re told about it.

Normal: you’re warned in advance, given the reason and offered a new plan. Worrying: you find out about the missed deadline on the day itself, the chat replies get longer and vaguer, and suddenly it turns out to be your fault.

What to do: ask for the reason in writing, agree that you’ll be warned in advance about any shift, and fix the stage deadlines in the contract. If missed deadlines become a pattern, keep a short timeline in the chat: what was promised, when, and what was delivered. You’ll need it if you have to part ways.

2. The price keeps going up

A budget can change honestly: you asked for a feature that wasn’t in the brief, or the accounting system returns data differently than everyone assumed. A good contractor explains the change and the price before doing the work. The dishonest scenario: they lowballed the price to win the deal and now make up for it with extra charges for things that should have been included from the start.

What to do: require a written explanation of every extra charge, tied to the scope of work. Any change of scope gets its own approval before anyone starts working on it. If there are no explanations and the extra charges never stop, compare the remaining work against a quote from another contractor. Sometimes leaving a project halfway is cheaper than paying extra until the end.

3. Before the contract you were the main client, after it you’re one of many

While they’re selling, the manager replies within five minutes and suggests ideas on their own. After signing, the replies come a day later, and the initiative always comes from you.

What to do: say honestly what isn’t working for you and agree on a rhythm: a short weekly report or call, a response time during working hours. Often that’s enough, because the problem is an overloaded manager, not unwillingness to work. If nothing changes after that conversation, the problem is no longer the manager.

4. No interim demos

They promise to show you “tomorrow”, then “next week”, then send a screenshot. A screenshot doesn’t prove that the menu opens, the filter filters and the form actually sends an enquiry.

Usually one of two things is behind this: the work has stalled because people are busy with other projects, or it’s moving much more slowly than claimed.

What to do: agree at the start that after each stage you get access to a test version at a separate address and can click around it yourself. For our distributor that means, for example, a catalogue with the first hundred products and a working filter long before the full launch. That way you see problems while they’re still cheap to fix.

5. You don’t know who is building your site

Only the manager is in the chat. When you ask about the developer, the answer is “he’s very busy, I’ll pass it on”. Sometimes that’s just a way to protect the team’s time. But sometimes the project was quietly subcontracted, or instead of the experienced developer mentioned during the sale, an intern is writing the code. Every extra link in the chain stretches the timeline and raises the chance that something gets lost along the way.

What to do: ask for at least one meeting with the person who writes the code. A conscientious contractor will arrange it without any problem. If you’re told why it’s impossible, remember that explanation.

During the process everything looks blurry; in a table it becomes obvious.

Don’t choose a contractor on a single criterion: the lowest price, loud advertising or “a friend used them”. And even if the contractor is an old friend of yours, you’re business partners: contract, acceptance, reports.

What the contract should include

A website contract doesn’t have to be thick, but a few things in it should be spelled out explicitly:

• Scope of work. A list of pages, features and integrations, ideally as an annex with the brief or the specification. Anything not listed counts as separate work, and that’s fair to both sides.
• Stages and payment in instalments. For example: a deposit to start, then payment after acceptance of each stage (structure and prototype, design, development, launch). Every payment is tied to a result you can see.
• Stage deadlines, and how they shift if the delay is on your side (you didn’t provide the copy, approvals took a long time).
• Owner of the domain and hosting. The domain and hosting are registered to you or your company, with your contact email. The developer gets access for the duration of the work.
• Rights to the code and design. There’s a legal nuance here. Who owns the rights to the design and code depends on the law of the country. In Ukraine (Article 430 of the Civil Code), the rights to a work created on commission belong to the creator and the client jointly, unless the contract says otherwise. In Germany, the author remains the owner of the copyright, and the client receives rights of use (Nutzungsrechte, § 31 UrhG), whose scope is defined by the contract. Either way, without a separate clause you may turn out not to be the sole owner of your own site, or to have fewer rights to it than you thought. Ask for the transfer of rights to the design and code to be written out explicitly (except for third party libraries and plugins, which have their own licences), and show the wording to a lawyer.
• Handover of access and files. What exactly you get after launch: admin access to the site, hosting, DNS, email, analytics and ad accounts, plus a full copy of the files and the database. A list, not “everything necessary”.
• Acceptance of work. How you check it, how many days you have for comments, what counts as a bug and what counts as a new request. The acceptance certificate is signed when the site works, not when it was shown on the manager’s laptop.
• Warranty. The period during which the contractor fixes bugs in the delivered work for free.
• Support after launch. Better as a separate contract: what’s included, how quickly they respond, how much it costs, how to end it.

Agree on communication in advance

For one person a reply after two hours is normal, for another it’s already disrespectful. Agree at the start: the messenger, response time during working hours, how often you get reports and demos. One line in an email after the first meeting removes half of the future arguments.

Keep a backup option

Keep the contact of one or two teams you talked to during the selection. You can use them to sanity check a new quote and timeline, and you have somewhere to go if the collaboration doesn’t work out. Code, access and a copy of the site on your side make such a switch painful, but possible.

A typical situation looks like this. The site is built, it works, the final payment is made, everyone is happy. A year later you decide to invest in promotion and go to another team. The first thing they ask for is access to the admin panel, hosting, domain and analytics. And you have never seen any of it.

The old developer politely replies that the site is on their server, they can’t give access, but they’d be happy to take on the promotion themselves. The domain is also registered to the studio. Formally there’s nothing to claim: the contract covered development and launch. Sometimes the only way out is a new site on a new domain.

To avoid this, the rules are simple, and none of them requires technical knowledge:

1. Register the domain to yourself or your company. Even if the developer does the paperwork, you should be listed as the owner, with your email, which you have access to.
2. Open the hosting on your own account and pay from your own account. Give the developer separate access.
3. After launch, gather all access details in one place: the domain registrar, hosting, the site’s admin panel, DNS, email on the domain, analytics, Search Console, ad accounts. Keep them in a password manager, not in chat history.
4. Ask for a short training session: how to add a product, change a text, upload a photo. This can be written into the contract as part of the handover.
5. When the collaboration ends, change the passwords or remove the former contractor’s access. It’s ordinary hygiene, and there’s nothing to be offended by.

If you’re already in a situation where the contractor is unreachable and you have no access, a step by step plan for getting it back is laid out in the article “The contractor disappeared. Who controls your website now?”.

Save it and go through it before signing:

• There’s a brief, and all candidates quoted the same project
• The type of contractor fits the task, not the lowest price
• Three or four live portfolio sites checked: they open, work on a phone and aren’t in the PageSpeed red zone on mobile
• You know who exactly will build the site
• The price is explained item by item, it’s clear what’s included and what isn’t
• The domain and hosting will be in your name from day one
• The contract covers scope, stages, payment in instalments, rights to the code, a list of access details, acceptance and warranty
• You’ve agreed how and how often you’ll be in touch
• You have the contact of at least one backup contractor

A good developer is transparent at every step: you see who is doing the work, what’s already done, what you’re paying for and what will be yours after launch. Many unpleasant website stories start with a domain in someone else’s name, a contract without a list of work and payment upfront.

If you’d like to look at your current site through the eyes of an outside specialist before you look for a new contractor, start with a free website check. And if you already have a brief and you’re looking for a team, write to us: we’ll look at the task and tell you honestly whether we’re the right fit.