Two proposals for the same project can look almost identical on the page and turn out to be completely different purchases. The gaps rarely show up in the summary. They show up nine months later, when you want to change something and discover you cannot.
These are the questions worth asking anyone before you commit, and what the answers tell you.
1. Who owns the code and the domain?
The only good answer is: you do, in your name, from the start. Hosting is a fair exception, and plenty of people sensibly pay someone else to run their servers. The domain registration and the repository are different. Some developers keep those in their own name, which is presented as convenience and functions as leverage. If moving away from them would mean rebuilding, that is a commercial position, not a technical one.
Ask specifically. It is common for the code to be yours while the domain quietly is not.
2. When will I first see something working?
If the answer is near the end, you are carrying the risk of a misunderstanding for the entire project. Interfaces are almost impossible to agree on in prose: everyone reads the same requirement and pictures something different, and nobody finds out until it is built.
A good answer puts something clickable in front of you early, while changing direction is still cheap.
3. What exactly is in scope, and what is not?
Vague scope is where relationships go wrong. You expect something to be included, they expect it to be extra, and both of you are reading the same sentence. Ask for the flows, the kinds of user, and the integrations to be written down explicitly, including the things deliberately left out.
A proposal that lists what it excludes is usually written by someone who has done this before.
4. Who will actually do the work, and who will I talk to?
Some agencies sell with senior people and deliver with junior ones. Others route everything through an account manager, which adds a translation layer between what you said and what gets built. Neither is disqualifying, but you should know which you are buying.
5. What happens if I want to change something halfway through?
You will want to change something. The right answer treats small changes as normal and expected, and handles genuinely new scope as a separate conversation you agree to first. The wrong answers are at both extremes: rigid refusal, or a cheerful yes that quietly accumulates into an invoice you did not expect.
6. What is included at launch that I would otherwise have to arrange?
Deployment, domain and DNS configuration, SSL, analytics, error reporting, uptime monitoring, email delivery, and backups. Each one is small. Together they are the difference between a project that is finished and a project that is handed to you as homework.
7. Will the content be in the HTML?
This sounds technical and is commercially significant. If your pages arrive as an empty shell and fill in with JavaScript afterwards, every system that reads your site has to run that JavaScript. Google usually will, eventually. Social preview crawlers do not, and the AI assistants that increasingly answer buying questions mostly read the raw HTML.
Ask them to show you view-source on something they have built and find a sentence from the middle of the page.
8. How will it perform on a mid-range phone?
Not on a laptop on office wifi. Most of your traffic will be on a phone on a mediocre connection, and that is where the gap between a fast site and a slow one turns into a gap in revenue. Ask for a real example you can test yourself rather than a score in a report.
9. What is the ongoing cost, and who am I paying?
Hosting, domain, email delivery, monitoring, and any usage-based services are real ongoing costs, and they should be modest for most small applications. Whether you pay the suppliers directly or have your developer run it all for you is a fair choice either way, and plenty of people would rather never look at a server. What matters is that you are told the figure before you commit, that the domain is in your name, and that you could move the whole thing elsewhere if you ever wanted to.
10. What happens after launch?
Launch is when you find out what you actually built, and something always surfaces in the first few weeks. Ask what support is included, what happens after that, and whether you are required to be on a retainer to get a bug fixed. Requiring one is a reasonable business model and you should know about it in advance.
11. Can I edit the content myself?
Sometimes the honest answer is that you should not want to. For content that changes twice a year, a content management system is more overhead than it saves, and a good developer will tell you that rather than sell you one. For content that changes weekly, not having one will drive you mad.
The answer matters less than whether they asked how often your content actually changes.
12. What would you tell me not to build?
This is the most revealing question on the list. Everyone can tell you what they would build. Someone who can immediately name a feature in your brief that is not worth the money has thought about your problem rather than your budget.
An enthusiastic yes to absolutely everything is not a good sign. Roughly half the features in a typical first specification are never used enough to justify what they cost, and you cannot reliably tell which half in advance. You want someone who will say so.
Three answers that should worry you
- "We will host it for you" with no answer to what happens if you leave. Managed hosting is a perfectly reasonable thing to buy. Managed hosting you cannot walk away from is not.
- A quote given without anyone looking at the system you need to integrate with. That is a guess presented as a number.
- A guarantee of search rankings. Nobody can promise positions, and anyone who does is either inexperienced or selling something that will not last.
The one thing that saves the most money
Build less, properly. Cut the first version down to the single flow that carries the value, ship it, and add the rest once real people have used it. It is not a compromise, it is usually a better product, and it is the only reliable way to find out which half of your specification actually mattered.
The things not worth economising on, in our experience: the data model, because it is the most expensive thing to change later; authentication, because getting it wrong is a security incident rather than a bug; and whether it is fast, because a slow product is abandoned regardless of what it does.