How to hire a freelance developer for a business web project

Hiring a freelance developer is not simply buying a website. It is a decision about how you will define, build and maintain part of your business.

That distinction matters because a website can look finished and still solve nothing. It may load quickly, look clean and use a recent technology, yet fail to explain a service, make an enquiry difficult or leave the team without access to key accounts when the project ends.

I would not begin by asking for a price for “a website like this”. I would begin with a more useful question: what should this project achieve for us to say in six months that it was worth doing?

For a small business or a new initiative, my default recommendation is to define a small, useful first version. A website that explains an offer clearly, supports contact or handles one specific process usually creates more value than a long list of pages, animations and integrations nobody has validated. You can expand later, with data and without panic.

Technology matters, of course. Account ownership, acceptance criteria, content and maintenance matter at least as much. A good professional helps you make those decisions before they become code.

When a freelancer is a good fit and when they are not

A freelance developer is often a strong fit when one person can make decisions, the project has an understandable goal and communication can be direct. Examples include a service website, redesign, landing page to validate an offer, focused internal tool or an integration between existing products.

They can also work well on more complex projects when the scope is divided into phases and someone on the business side can set priorities. The key is not that the project is small. It is that important decisions do not depend on an impossible chain of approvals.

It is usually not the best option when you need a large team available at once, continuous coverage with demanding service-level commitments or many independent specialist roles from day one. You may need an agency, an in-house team or a combination of people in that situation.

Before looking, I would review these questions:

Question	If the answer is “no”
Do we know the problem we want to solve?	The first phase should be discovery, not fixed-scope development.
Is there someone who can decide priorities?	The project may get stuck in review cycles.
Can we provide content, system access and timely answers?	The development schedule will not be the only source of delay.
Do we know what must happen for delivery to be accepted?	Arguments will appear at the end, when changes cost more.
Will the business own the important accounts?	You will depend on somebody else to operate or leave the project.
Do we have an idea how it will be maintained afterwards?	A one-off delivery can turn into immediate debt.

You do not need every answer before you make contact. It helps to know which questions belong to the business and which you expect the person you hire to help resolve.

Start with the problem, not the technology

“I need a WordPress website”, “I want a React app” and “I need someone who knows AI” are weak starting points. They name a solution before explaining why it is needed.

A useful first conversation should cover:

• who will use the result;
• what they need to understand, do or stop doing;
• what happens today and where time, money or customers are lost;
• which content, systems or materials already exist;
• which constraints are real: date, budget, legal, brand, accessibility or integration;
• what is outside the first delivery.

For example, “we need a more modern website” is too broad. “Prospective customers do not understand which service to buy, the current form creates poor-quality enquiries and the team takes two days to respond” gives us something to discuss: structure, content, forms and follow-up. There is something to build and something to measure.

Technology should come after the context is understood. WordPress is a reasonable choice in some cases. A static site is easier to maintain in others. A tool with permissions and internal data may need custom development. Choosing the technology before defining the work often turns a proposal into a component list rather than a plan.

What a first proposal should include

A useful proposal does not promise that everything will be easy. It makes decisions and boundaries visible.

At a minimum, it should explain:

• the project goal and who it is for;
• the first delivery scope: pages, flows, integrations and content;
• what the client needs to provide and when;
• which decisions remain open and how they will be made;
• what is explicitly outside the price;
• a working sequence with review points;
• how each part will be tested and accepted;
• what is handed over at completion: access, code, documentation and accounts;
• what support or maintenance is available after launch.

I would not expect a hundred-page specification before starting. In an uncertain project, that can create false confidence. I would expect assumptions to be written down, though. If the estimate assumes the client provides copy, photography or CRM access, say so. If an integration relies on a supplier API, say that too.

A good proposal separates what is needed to launch from what can wait. That protects both the client and the freelancer. It creates a first working version without pretending that every idea for the next two years must be decided this week.

How to compare quotes without looking only at price

Two quotes with the same total can describe different projects. One may include design, content, testing and deployment. Another may deliver an installed template only. Comparing totals without comparing scope is a quick way to hire incompatible expectations.

I would compare these dimensions:

Dimension	What to check
Problem and goal	Did they understand the case or reuse a generic proposal?
Scope	Does it name pages, flows, integrations and exclusions?
Process	Are there reviews before everything is built?
Content and design	Who provides copy, images, brand materials and approval?
Quality	Does it cover functional testing, responsive behaviour, basic accessibility and performance?
Delivery	Does it include deployment, configuration and a way to confirm it works?
Ownership	Who controls the domain, hosting, repository, analytics and external accounts?
Maintenance	What happens when an incident occurs or something needs updating?

The cheapest quote can be right if the scope is genuinely small and the risk is low. It can also omit exactly what will be needed later: content, migration, forms, analytics, testing, support or account access.

Ask which assumption is most likely to change the price or schedule. It is a simple question and often shows whether the person has considered the real project risks.

Ownership and accounts: the point people forget until it hurts

Domain, hosting, code repository, analytics, transactional email, form accounts, payment providers and other external services should not exist only in a freelancer’s personal account.

The business needs access to what it needs to operate. That does not mean managing every technical detail or changing passwords every week. It means that if the relationship ends or you need another provider, you can recover the domain, data, code and configuration without starting again.

Before work starts, make clear:

• who owns the domain and has administrator access;
• where the website is hosted and whose account holds it;
• where the code lives and who can download it;
• which data is collected and who controls the accounts that process it;
• which licences, templates, paid services or APIs have recurring costs;
• which documentation is delivered at the end.

This is not distrust. It is a normal condition for a project to survive changes in providers, people and priorities.

Communication, reviews and acceptance

Direct communication is an advantage of working with a freelancer. It does not remove the need to record decisions.

Agree from the start who can approve changes, when work will be reviewed and what it means for a phase to be accepted. For a website, the first review may cover structure and content, the second design on the main screens and the third a working version in a test environment. For an internal tool, reviews may follow the most important user journeys.

Each review should answer a different question. If typography, information architecture, business rules and budget are discussed in the same call, decisions become tangled and agreements are forgotten.

Also agree how change requests are handled. Changes are normal. The problem begins when a new request is treated as though it was always included. A simple process of “this changes scope, price or date, so let us confirm it first” prevents misunderstandings on both sides.

Quality before launch

Do not judge delivery from a screenshot alone. Check what happens when a real person uses the result.

For a business website, I would include at least:

• review on mobile and desktop;
• working forms and confirmation messages;
• checked links, redirects and error pages;
• copy reviewed by someone who knows the business;
• basic accessibility measures: keyboard navigation, alternative text where appropriate and sufficient contrast;
• reasonable loading time for the published content;
• analytics, privacy and consent configured for what the site uses;
• verified access and recovery for important accounts.

For an application or integration, add tests for permissions, expected failures, duplicate data, retries and recovery. The details depend on the project, but the principle is the same: acceptance criteria should cover normal use and foreseeable failures.

Maintenance and life after launch

Publishing does not end the work. Copy changes, security updates appear, domains expire, a form stops sending messages or a provider changes its API.

Ask what needs regular review, which tools carry a fee, what alerts exist and how an incident is reported. Sometimes an update guide and a few support hours each month are enough. In other cases, an application handling sensitive data needs a clearer maintenance arrangement.

There is no single correct answer for every project. The important thing is that it does not arrive as a surprise after launch.

Warning signs when hiring

Some proposals deserve a closer look:

• a fixed price without questions about content, users or integrations;
• guaranteed search rankings or business results without explaining the work;
• technology chosen before the problem is understood;
• many features included, but no sequence or acceptance criteria;
• no mention of domain, hosting or account ownership;
• no reviews until the end;
• a quote covering design and development but not testing or deployment;
• vague answers about maintenance, security or access recovery;
• pressure to pay or launch before you can review what was agreed.

Be careful with the opposite extreme too: a huge document trying to predict every screen before anyone has spoken to users or tested the content. Planning reduces uncertainty. It does not make uncertainty disappear.

A project path that usually works

The approach I trust most is: understand, narrow, build, test, then expand.

1. Define the intended outcome and current problem.
2. Gather content, references, access and known constraints.
3. Agree a first delivery with visible exclusions.
4. Review structure and priorities before visual detail.
5. Build a working version and test it in an appropriate environment.
6. Fix the problems that appear in real use.
7. Launch with accounts, access and documentation handed over.
8. Choose later improvements from data and feedback, not an old wish list.

This sequence does not make a project automatic or remove difficult decisions. It makes them cheaper. If an idea is less useful than expected, you can change it before it pulls six weeks of related work along with it.

Final recommendation

For most small-business web projects, I would look for a freelancer who asks good questions, turns the problem into manageable scope and leaves important accounts under the business’s control. I would begin with a useful first version and avoid committing budget to features that do not yet answer a clear need.

The right person is not the one who lists the most technologies. It is the person who can explain what they will build, what they will not build yet, how you will check it works and what you will need to maintain it afterwards.

My web design in Granada page explains how I approach service websites, landing pages and redesigns for businesses that need better enquiries.

Frequently asked questions

Do I need a complete specification before making contact?

No. A goal, current context, references and known limits are enough for a first conversation. The person you hire should help turn that into more precise scope.

How do I know whether a quote is too cheap?

You cannot tell without comparing scope. Review what it includes for content, design, testing, deployment, accounts, support and changes. A low price can be right for a small delivery. It is concerning when it hides essential work.

Should I hire by the hour or by project?

Stable scope can suit a project price. If there is still uncertainty, an initial hourly phase or limited budget may be more honest. What matters is recording what is decided and what changes.

Who should own the domain and hosting accounts?

The business should have administrator access to, or be the account holder for, important accounts. The freelancer can manage them technically, but should not be the only person able to recover the project.

What happens if I want to change provider?

You should be able to obtain access to the domain, hosting, repository, data, configuration and documentation. Agree this before starting, not when you need it.

Is maintenance needed after launch?

It depends on the technology and integrations, but every website needs at least a review of access, renewals, forms and content. An application or website with external services usually needs a more continuous plan.