5 questions to ask before hiring any web development

There’s an information gap that makes buying web development much harder than it should be. The client knows what they want to achieve. The provider knows how it’s done. And in between lies the space where most misunderstandings happen, where projects don’t turn out as expected and invoices balloon without anyone quite understanding why.

The most effective way to close that gap isn’t to become a technical expert before asking for a quote. It’s to ask the right questions. The ones that reveal how the provider really works, what they prioritize and what will happen when things don’t go exactly as planned.

Question 1: Who will own the code when the project is finished?

This question seems obvious. The answer isn’t always.

Some providers work with proprietary frameworks, privately licensed visual builders or components that belong to them and don’t transfer with the project. In those cases, the client gets a website that works but that they can’t maintain, modify or hand over to another developer without losing functionality or paying for extra licenses.

The answer you’re looking for is unequivocal: the code developed specifically for your project is yours. You can take it to another provider, you can modify it, you can do whatever you need with it. No conditions, no fine print.

If the answer includes caveats like “it depends on the components” or “some parts belong to our platform,” dig deeper before signing. Those caveats can turn into costly dependencies in the long run.

Question 2: What documentation do you deliver with the project?

A web development project without documentation is a project only the people who built it can maintain. If that provider isn’t available in the future (because they change their prices, because they disappear, or simply because you can’t get your schedules to line up), you’re practically starting from scratch.

The minimum documentation that should come with any serious project includes: a description of the system architecture, instructions for the development environment, documentation of the integrations and APIs used, and a guide to the most common maintenance tasks.

A provider who doesn’t document isn’t necessarily dishonest. They may simply work fast and without processes. But the result for the client is the same: dependency.

What the answer reveals

If the provider answers precisely (“we deliver an architecture document, a README with environment instructions and a user manual for the custom features”), you’re talking to someone who works with processes. If the answer is vague or the topic seems to make them uncomfortable, it’s a sign that documentation isn’t a regular part of how they work.

Question 3: How do you handle scope changes during the project?

In almost every development project, the client asks for something that wasn’t in the original brief. Not because of poor planning, but because it’s impossible to anticipate every detail before you see the project take shape. The question isn’t whether it will happen, but how it’s handled when it does.

A mature provider has a defined process: the change is assessed, quoted and approved before it’s carried out. There’s transparency about the impact on timeline and cost before anyone starts working on the new piece.

A provider without a defined process either absorbs changes silently until the project ends and the final invoice looks nothing like the original, or rejects them one by one, creating tension with the client.

Neither situation is good. What you want is a clear process agreed on before you start.

Question 4: What does post-launch support include, and for how long?

Launch isn’t the end of the project. It’s the moment the project starts living in real conditions, with real traffic and real users doing things nobody anticipated in testing.

Something always comes up after launch. Unexpected behavior on a specific device. A bug that only happens under certain conditions. An integration that fails with real data that didn’t exist in the test environment. What sets providers apart isn’t whether this happens, but how they respond when it does.

What you should expect

A minimum post-launch warranty period (usually between 30 and 90 days) during which bugs attributable to the development are fixed at no extra cost. And a clear proposal for what happens after that period: whether there’s a maintenance contract, with what response times and at what cost.

If the provider doesn’t have a clear answer to this question, you’re taking on a risk you haven’t priced in.

Question 5: Can you show me a project similar to mine that you’ve delivered?

Not a generic portfolio. A specific project, with an honest description of the challenges it faced and how they were solved, and ideally the option to talk to that client if you have questions.

This quickly separates providers with real experience in the type of project you need from those with general experience who have never solved anything like yours.

A provider who has done ERP integrations can show you how they did it, what problems came up and what they learned. One who has never done it may present it as simple because they don’t know exactly what they’re going to run into.

How to read the answer

The best answer is a concrete example with real context. The second best is honesty: “we haven’t done exactly this, but we’ve solved similar problems in these projects and this is what we learned.” What you don’t want is a generic answer that sidesteps the question, or a portfolio of screenshots with no context about how what you’re seeing was built.

Checklist: signs of a mature technical provider

• Answers all the questions above precisely and without discomfort.
• Asks questions before quoting, not after.
• The quote details the scope precisely enough for you to know exactly what is and isn’t included.
• Proposes a validation process before launch, not just a final handover.
• Has client references willing to talk about their experience.
• Is able to tell you when something doesn’t make sense or when there’s a better solution than the one you asked for.

Frequently asked questions

Is it normal for a provider not to want to reveal technical details before signing?

Up to a point, yes. No provider is going to share their full methodology before there’s an agreement. But the 5 questions in this article don’t ask for technical secrets: they ask for information about processes, contract terms and past experience. A provider who refuses to answer them before signing is putting their interests ahead of yours from the start.

What if the cheapest provider answers all the questions well?

Then it’s probably a good option. Price isn’t the only indicator of quality, and some providers do good work and charge less because they have leaner cost structures or because they’re in a growth phase where building a client base comes first. The questions aren’t designed to weed out affordable providers, but to weed out those without clear processes, whatever their price.

When is the best time to ask these questions?

Before asking for a quote, if possible. Many of these questions can be asked in the first conversation or discovery meeting. Asking them at that point has 2 advantages: it helps you decide whether it’s worth continuing with that provider before investing more time, and it signals to the provider that you’re a client who knows what you’re asking for, which usually translates into more professional treatment from the start.

You might also be interested in: The real cost of a cheap website · When to outsource and when to hire · How to tell if your current agency is serving you well

At Baqueiro we answer these 5 questions before you even ask them, because they’re part of how we explain the way we work from the very first contact. If you have a project in mind and want to get off on the right foot, let’s talk.