How to Choose a Web Development Contractor: 12 Questions to Ask.

To choose a web development contractor for a website or online store, you do not need to understand code. It is enough to ask 12 questions about process, code ownership, testing, price and support, and to listen closely to how specific the answers are. A reliable team answers with numbers, examples and documents; an unreliable one answers with general phrases about an "individual approach".

Below are the questions we ourselves recommend clients ask, including us. A tech lead with eleven years of experience in PHP and Laravel has seen enough projects stall halfway to know that problems start not with the code but with vague agreements at the start.

Why choosing a contractor is risk management

A website or store is not something you can return to the shop. If the contractor disappears after six months, you are left with partially written code, someone else's access credentials and lost time. So the choice should be made as risk management: what exactly can go wrong, and what can you verify right now.

The main risks are typical:

• Loss of control. The code, domain, hosting and services are registered to the contractor.
• A bloated budget. The starting price is understated, and then every change is "extra work".
• Low quality. The site "works on the developer's laptop" but breaks on phones or at payment.
• Dependence on one person. Nobody can pick up the project when the developer gets ill or leaves.

The twelve questions below are grouped by these risks. Ask them in writing: answers in an email are easier to compare and to quote later.

Questions about the result and the price

1. What exactly will I get at each stage?

A good answer is a list of artifacts: page structure, Figma mockups, a working prototype, a staging environment, the final release. A bad one is "design first, then development". Every stage should end with something you can see and accept.

2. What is the price made of, and what is not included?

Ask for a breakdown by stage or by feature, not a single figure. We publish starting prices openly on the pricing page: a landing page from UAH 25,000, a corporate website from UAH 60,000, a store from UAH 150,000. The exact cost depends on scope, design, integrations and deadlines, and it should be explained, not just "depend".

Separately ask about the things that usually stay outside the estimate: copy and photos, paid licenses and fonts, hosting, domain, third-party services. If they are not named, you will find out about them at the end.

3. How are changes in requirements priced?

Changes are inevitable. The question is how they are handled: a fixed price with a separate estimate for changes, or hourly work with a cap. The right answer is that every change is first estimated in writing and you approve it before work starts. The wrong one is "we'll do it, we'll settle up later".

For comparison: hourly rates on our team are open, from $20 per hour for a designer to $32–35 for a tech lead. You do not have to work hourly, but you should understand what any figure is made of.

4. How long will it take and what affects the timeline?

Realistic benchmarks: a landing page takes 2–3 weeks, a corporate website 5–7 weeks, a store 10–14 weeks. If a contractor promises a store with payment, delivery and CRM in two weeks, they either did not account for testing or do not grasp the complexity of the integrations. Add your own time to this: approving mockups and content often delays projects more than development does.

Questions about code, access and ownership

5. Who owns the code, and will I get access to the repository?

The only acceptable answer: after payment, the code and all materials belong to you, and the repository is created on your account from the start or transferred to you. If development goes in the contractor's private repository and you get an "archive at the end", that is a risk: you cannot see progress and have no guarantees.

The same applies to the domain, hosting, payment provider accounts and analytics. Everything tied to money and customer data must be registered to you.

6. What will the site be built on, and why that stack?

Not to test your knowledge of terms, but to hear the reasoning. For a store with non-standard logic, integrations and its own admin panel, Laravel is a reasonable answer; we discuss this in more detail in Laravel vs OpenCart and WordPress for Ecommerce. For a quick landing page or content site, simpler solutions are enough. It is suspicious if a contractor offers the same stack for every task just because "that's how we work".

Ask separately: will it be easy for another team to take over the project? A popular stack, documentation and code structure that follows common practices are insurance against dependence on a single vendor.

7. Is there documentation, and what happens if you stop working with us?

At a minimum: deployment instructions, a description of environment variables, the database schema and a list of integrations. Ask directly: "If in a year we decide to work with another team, what will you hand over and how fast?" A good contractor does not take offense at this question; they have a ready answer.

Questions about quality and testing

8. Who tests the site before launch, and how?

This question filters out the most. The typical answer from a weak team: "developers check it themselves". A developer tests what they wrote, the way they intended. Independent testing looks for what nobody anticipated: an empty cart, pressing "Place order" twice, a long surname in a form, an old iPhone.

Ask for specifics: is there a test plan, which devices and browsers are checked, how bugs are recorded and how many rounds of fixes are included in the price. For a store, checkout testing is a topic of its own; we described the typical mistakes in Why Orders Get Lost at Checkout: 7 Common Bugs. If the contractor has no QA of its own, you can order independent website testing separately.

9. Which speed and accessibility metrics do you guarantee?

Not "a fast site" but measurable thresholds: for example Lighthouse on mobile and Core Web Vitals. Ask where and how these numbers will be measured, and whether optimizations are included in the price. How to check speed yourself is explained in Core Web Vitals for Store Owners.

10. How do you handle SEO during development?

SEO added "after launch" almost always means rework. Ask whether every page will have a unique title and description, a canonical, structured data, a sitemap and correct redirects from the old site. If you already have a site and are migrating, redirects from old URLs are a separate question that must be in the plan before development starts, not after traffic drops.

Not sure about a contractor's answers? In a 90-minute consultation a tech lead will go through the commercial proposal and the requirements and tell you which risks they see. The price is from UAH 3,000; details are on the Tech Lead page.

Questions about process, contract and support

11. What does communication look like, and who is my contact?

Find out before work begins: who manages the project, how often there will be reports, where tasks are tracked, and how fast questions get answered. Good practice is a regular short report (what is done, what is in progress, what is blocking) and access to the task tracker. A bad sign is communication only through a manager who passes questions to "the developers" and comes back a week later.

Also ask who exactly will write the code. In agencies a switch happens: one specialist sells, and another, more junior, does the work. We work openly: you know who the tech lead is, who the QA is and who builds the layout, and the process is described on the Process page.

12. What does the contract say about payment and post-launch support?

Check four points:

1. A formal contract with scope, deadlines, milestones and the parties' liability.
2. Payment by milestones tied to acceptance, not to the calendar. Our scheme is 30 / 40 / 30: an advance, payment after the main development and a final settlement after acceptance.
3. A warranty period for fixing defects. Ours is 30 days after launch.
4. Support after release: what is included, what it costs, who responds to incidents. Support plans start from UAH 8,000 per month; more on the website support page.

It is very useful to spell out what counts as acceptance of the work: for example, the absence of critical and serious defects from the test plan list. Without it, "done" means something different to each side.

Red flags that do not depend on the answers

Sometimes a contractor's behavior during negotiations already shows what will come next. Watch for these signs:

• A price without a breakdown and without a conversation about requirements. If the estimate came after a five-minute call, it is a price "out of thin air".
• Time pressure. "The discount is valid until Friday" is almost always marketing, not business logic.
• No questions for you. A good contractor asks many questions about the audience, sales processes and existing systems. If there are no questions, they do not intend to dig in.
• A portfolio with no explanations. Screenshots without a description of the task, the role and the result. Ask them to show what exactly the team did and what changed for the business.
• A refusal to show examples of code or process. It is not necessary to publish someone else's code, but talking about the approach should be possible.
• A price far below the market. If a proposal is half the others, testing, design or time reserve has been removed somewhere.

How to compare proposals in practice

Collect at least three proposals and put them into a table. Do not compare only the total; compare the composition.

Once filled in, it often becomes clear that the cheaper proposal simply lacks rows that the more expensive one has. If you are unsure how to assess the technical points, you can bring in an outside specialist for a few hours: a review of the proposal and requirements costs less than one rework.

A one-week selection mini-process

To avoid dragging the choice out for months, you can fit it into five steps:

1. Day 1. Write a short task description: goal, audience, mandatory features, integrations, desired deadline and budget range. The brief is convenient for this.
2. Days 2–3. Send the task to 3–4 candidates and ask them to answer the 12 questions in writing.
3. Day 4. Hold short calls: check how well people understand your task.
4. Day 5. Put the proposals into a table and review the contract.
5. Days 6–7. Ask for a small trial task or a paid discovery stage before signing a big contract.

A small paid pilot is the best check. In a week you can see how the team communicates, keeps deadlines and reacts to feedback.

Summary

A good contractor is not afraid of any of these 12 questions, because they already have answers: about artifacts, price, code, testing, contract and support. Bad answers do not always mean dishonesty, but they do mean a risk that you should consciously accept or remove before signing the contract.

Want us to answer these 12 questions about your project? Fill in the brief, and within 1 business day we will send an estimate with a breakdown by stage, a timeline and a list of what is not included in the price.