Nearly every agency relationship that goes wrong was readable in the proposal.
Not because the agency lied. Because nobody asked the question whose answer would have shown the mismatch, and both sides found out in month three instead.
These are the nine I would ask. They take about twenty minutes, and the way they are answered tells you more than the answers themselves.
1. Who specifically is doing the work, and will they still be on it in six months?
The oldest pattern in the industry is that seniors sell and juniors deliver. It is not always wrong — plenty of good work is done by people early in their careers with proper review — but you should know which one you are buying.
Ask for names and seniority. Then ask whether those names change after month two.
A good answer is specific and slightly uncomfortable: these two people, this is their experience, here is who covers holiday. A bad answer talks about "the team" and "our process" without naming anyone.
2. Who owns the code?
Ask for intellectual property to transfer to you on payment, and read what the contract actually says rather than what the salesperson says.
Some agencies licence the work to you instead of transferring it. That means you cannot take it to another developer without a renegotiation, which is a very strong position for them to be in and a very weak one for you.
Also ask about their own tooling and boilerplate. It is entirely reasonable for an agency to keep ownership of components they built before you existed and use across clients — we do — but you need a perpetual licence to use them inside your product, in writing.
3. Can I see the repository from day one?
Yes is the only acceptable answer.
You should have access to the code as it is written. An agency that releases the repository only on final payment has built a hostage situation into the arrangement, whatever reasonable-sounding language it is wrapped in.
The same goes for hosting, domains and third-party accounts. Everything should be in accounts you own, with them invited in. Not the reverse.
4. What is not included?
Quotes are compared on the total and decided on the exclusions.
Ask specifically about hosting and infrastructure setup, staging environments, deployment pipelines, data migration, content population, third-party licence costs, handover documentation, and a support period after launch.
A cheaper quote missing four of those is not cheaper. It is a smaller piece of work with the rest arriving later as change orders, when you have no leverage left.
5. What happens when I want something changed mid-build?
This is where fixed-price projects break, and everyone knows it, so listen carefully to how it is handled.
A good answer describes a process: how a change is assessed, how it is priced, how you approve it before work starts. A bad answer is "we are flexible", which means there is no process and you will find out the price afterwards.
Worth saying plainly: a fixed quote is a bet both sides make before either knows enough. Products are discovered rather than specified. Any model that punishes you for learning something will eventually stop you asking for improvements, which is the real cost and it never appears on an invoice.
6. What does the payment schedule look like?
Staged against delivered milestones, not against dates on a calendar.
Paying half up front for a three-month build means that if month two goes badly you have spent 50% and have no leverage. Tie money to things you can look at.
For ongoing work, monthly in advance is reasonable, because the protection is that you can stop. That is why subscriptions should have no notice period — if cancelling is hard, the monthly billing was never the protection it appeared to be.
7. What happens if this does not work out?
Ask it directly. The reaction is informative.
You want a defined notice period, your code, designs and assets handed over in a usable state, and no dependency on anything only they can access. If the answer is vague or slightly offended, you have learned what you needed to.
8. Who maintains it after launch, and what does that cost?
Software is not finished when it launches, and the month after go-live is when the real defects appear.
Find out now whether they offer ongoing support, what it costs, and what response time it carries. An agency that builds and leaves is a legitimate business model, but you need to know that is what you are buying so you can line up whoever comes next.
The hidden cost is that version two of anything costs nearly what version one did, because a new team has to learn your codebase from scratch.
9. When would you tell me not to buy this?
The most useful question of the nine.
Everyone has cases where their service is the wrong answer. An agency that cannot name one of theirs either has not thought about it or is not going to tell you.
Our answers, for what it is worth: if you have an idea and no users, prototype it yourself first. If you need one thing built and then nothing, buy a project rather than a subscription. If you genuinely need eighty hours a week of product work, hire.
What good looks like
Specific names. Ownership transferring on payment. Repository access from day one. Exclusions written down. A real process for changes. Money tied to delivered things. A clean exit. Honest limits.
None of that requires trust. It is all checkable before you sign, which is the point.
Ours is all on one page: the terms cover what counts as a request, turnaround, pausing, cancelling, refunds and ownership, and the plan carries the prices with nothing hidden behind a proposal. If you would like to put these nine questions to us directly, thirty minutes and we will answer all of them.
