I regularly hear from companies who picked the wrong person to build their website. Sometimes the site was never finished. Sometimes it was, but it takes eight seconds to load and falls apart on a phone. Surprisingly often, the owner has no access to their own site.

Every single time, it was visible at the conversation stage. Below is what to look at, what to ask, and which answers should end the conversation.

Freelancer, agency, or do it yourself?

That's the first decision. Each has a real trade-off.

A freelancer — one independent developer

For:

  • Lower rates, since there's no office overhead
  • You talk directly to the person doing the work
  • Fast to start, little process to wade through

Against:

  • If they're ill or overloaded, your timeline moves
  • If you pick badly, they can go quiet mid-project

Best for: business sites, blogs, brochure sites and moderately complex shops — in practice, most of the projects in the price bands I've written about separately.

An agency — a team

For:

  • Several specialisms at once: development, design, search
  • Process and structure, so fewer things fall through
  • Support after launch, contractually
  • Experience across a lot of projects

Against:

  • Noticeably higher rates
  • Process sometimes gets in the way of moving quickly
  • Less direct contact with whoever writes the code
  • Small projects can end up low in the queue
  • A high price is not by itself a guarantee of quality

Best for: large builds with multiple integrations, where you need several specialisms at once and a guarantee the project doesn't stall when one person is off sick.

DIY — a site builder

For:

  • Cheap or free
  • Complete control, changes any time
  • Genuinely quick to get something up

Against:

  • Your time, which isn't free
  • Weaker search performance
  • You build what the platform allows, not what you need
  • Without someone maintaining it, it drifts out of shape

Best for: very small operations, if you have the time and the patience.

What to look for

You've picked a type. Now how do you judge the actual person?

1. Portfolio — look at real work

Test number one. Everyone has built something. The question is whether you like it, whether it looks professional, and whether it's anything like what you need.

Open the sites, don't just look at screenshots:

  • Do they load quickly?
  • Do they hold up on a phone?
  • Are they still online at all?
  • Are any of them comparable to what you want?

Warning sign: no portfolio, or every example visibly the same template.

2. Process — how do they actually work?

Worth asking:

  • What does communication look like week to week?
  • How often will I see progress?
  • Will I get access to the site while it's being built?
  • What does final sign-off involve?
  • Is it tested on different devices and browsers?

Good signs: they describe a process, show a timeline, mention testing, and ask questions of you.

Bad signs: "sure, I'll do it" with no questions, no explanation of the steps, and a deadline that sounds too good.

3. Communication and availability

Working styles differ and that isn't a problem in itself. I work asynchronously — I reply within a few hours, but I'm not sitting on the phone. Other people do better with a daily call. What matters is that they:

  • reply within a reasonable time
  • stay available for questions and changes
  • don't vanish for a fortnight without a word

Ask directly: how quickly do you normally reply?

4. Technical judgement

  • What do you build with, and why that?
  • Is search optimisation part of the build or an extra?
  • Do you check performance before launch, with real measurements?
  • Is there monitoring, so somebody knows when the site goes down?
  • How do backups work, and where are they stored?

5. Experience with your kind of business

Have they done anything in your sector?

  • If yes, they'll already know about the awkward parts — bookings, payments, catalogues
  • If no, they'll learn on your project. Not always a drawback; an outside perspective can be worth something

Not a requirement, but it makes the conversation easier.

Questions to ask before signing

Ask these, and get the answers in writing:

  1. What exactly is the scope? How many pages, which features, which integrations?
  2. What's the timeline? When do we start, when is there something to look at, when does it go live?
  3. What does it cost? Total, and what's the payment schedule?
  4. What happens after launch? How long is support included, and what does it cost after that?
  5. Who has access to what? Will I have the admin panel, the hosting, the code?
  6. How do we communicate? Email, Slack, phone — and what's the typical response time?
  7. What if I want changes? How many revisions are included, and what does the next one cost?
  8. What if I want to leave? Can I take the code and go elsewhere?
  9. Who's responsible for faults? If something breaks after sign-off, who fixes it and at whose cost?
  10. Is there a contract? I want this written down, not agreed verbally.

Good answers are specific. Bad answers are "we'll see" — or no answer at all.

Warning signs

1. A price far below everyone else. If a site should cost 15,000 PLN and someone quotes 2,000, you're getting a template with your logo on it, or an unfinished job.

2. No portfolio, or every example from the same theme. If you can't find original work, assume there isn't any.

3. Promises that can't be kept. "You'll be first on Google within a week" is untrue, and whoever says it either knows that or doesn't know the field. Ranking takes months.

4. Nothing in writing. If everything is agreed by phone and none of it lands in an email, you have nothing to point at when there's a disagreement.

5. No access to your own site. The worst one. If you can't get the admin panel, the database or the hosting, it isn't your site.

6. Starting work without asking you anything. A good developer asks about your sector, your competitors, your goals and who the customer is. Without those answers you get a site that fits everyone and convinces nobody.

7. Reluctance about a contract. "We don't need one, trust me" is a preview of how problems will be handled.

8. Slow to reply before you've paid. That's the best-case version of their responsiveness.

What the contract needs to cover

No project should start without one.

  • The exact scope — what will actually be on the site
  • Dates — when it's finished
  • Price and payment schedule
  • Support terms — how long, how many revisions
  • Access and ownership — who owns the code, the database, the domain
  • Liability — what happens when something goes wrong
  • Termination — how either side gets out

You don't need to be a lawyer. The contract protects both of you.

Final checklist

  • Look through the portfolio and open a few projects live
  • Assess the process — can they explain the steps?
  • Check communication — do they reply in reasonable time?
  • Check technical judgement — search, performance, security
  • Ask the ten questions above — are the answers specific?
  • Check the warning signs — suspiciously low price, no portfolio, no access
  • Insist on a written contract
  • Settle what happens after sign-off — support, fixes, liability

Choosing a developer is one of those decisions where the saving is only apparent. The difference between a good choice and a bad one rarely shows up in the first invoice — it shows up a year later. If you want to see what a site looks like when nobody asked these questions, I've collected the most common mistakes.

If you're mid-conversation with someone and something feels off, send it over. I'm happy to read a quote and tell you what I think of it, even if you end up hiring somebody else.