Most of what goes wrong on a software project is decided before any code is written, in a conversation nobody documented. These are the twelve questions that surface those decisions early: what you own, who does the work, what happens after launch, and what happens if the relationship ends.
They are written for Drupal work because that is what we do, but eleven of the twelve apply to any custom development engagement. Ask them of us too. If a supplier is uncomfortable with any of them, that discomfort is the answer.
Ownership: what do you walk away with?
1. Who owns the source code, and from what date?
Not "on final payment", but from what date. The difference matters because "on final payment" describes a handover event, and handover events are exactly what gets skipped when a relationship ends badly or a company stops trading.
Ask for the repository in an account your organisation owns, from the first commit. Then there is no handover to miss.
2. What exactly is included in "the code"?
Ownership is easy to claim and easy to hollow out. The specific version is: application code, custom modules, the theme, build tooling and deployment configuration, meaning the repository, not a deployed artefact and not access to a hosted instance.
If any part of the system is a proprietary component you cannot host or modify, you want to know that now rather than at renewal. Our position on this is here.
3. Is there any licence fee on our own system?
Per-seat fees and annual renewals on a platform you paid to have built are a recurring cost that scales with your success. Ask directly, and ask whether the answer changes as user numbers grow.
4. Whose name is on the domain, the DNS and the hosting account?
Give your supplier access. Do not give them ownership. This costs nothing to arrange at the start and is close to impossible to unwind from a position of weakness later.
Scope and price: what are you actually agreeing to?
5. When is the price fixed, and against what?
"Fixed price" before anyone has designed the architecture is a guess with a confident number attached; it will be revisited, and the revisiting happens when you are already committed.
A defensible answer names the artefact the price is fixed against. We commit a fixed price after the architecture is agreed, and for larger programmes we do that through a paid discovery engagement that produces the architecture, an integration map, a phased plan and a risk register. The bands and the structure are on our pricing page.
6. What happens when the scope changes (and it will)?
Every project changes. The question is whether there is a written change process with a price and an approval step, or whether changes are absorbed silently until the relationship sours over something that was never agreed.
7. How do payments align with delivery?
Large payments up front transfer risk to you. Payment on completion transfers it entirely to the supplier, which sounds appealing until you notice who that incentivises to cut scope at the end.
Milestone-based payment against demonstrable working software is the middle. Ours runs across four milestones, with working software in front of you before each one.
8. Will we see working software before we commit?
A proposal, a wireframe and a design mockup are all descriptions of software. Only working software tells you whether the thing you asked for is the thing you meant.
Ask whether you will see a prototype on your own data (not on sample data, which is designed to make everything look straightforward) and at what point.
The team: who is actually doing this?
9. Who will work on this, and are they employees?
Not the names in the pitch deck. The names on your project. Ask how much of the work will be subcontracted, and to whom.
This is not an objection to subcontracting: it is a question about whether the people who understand your system will still be reachable in a year, which determines whether a long warranty is worth anything.
10. Who fixes a defect found three months after launch?
The team that built it, or a support desk reading the code for the first time during your incident?
This question also explains warranty pricing. When the build team stays attached, nobody has to learn the codebase before they can fix it, which is most of why a long warranty is affordable to offer. When delivery and support are separate organisations, the reading-in cost is real and it gets recovered by making the warranty short, narrow or billable.
After launch: what have you actually been promised?
11. What is the warranty, what does it exclude, and is it in the contract?
Three parts, all of which need answering.
How long, and check that the term appears in the contract, not only the proposal. Ours is one year as standard, extendable up to three by agreement.
What it excludes: every honest warranty has a boundary. Typically: new feature development, breaking changes in third-party services, issues caused by modifications the supplier did not make, and infrastructure outside their control. A supplier who cannot list the exclusions has not thought about the boundary, and you will discover it during an incident instead.
Is it separately billed: if so, it is a support contract rather than a warranty. Ours is included in the project price.
12. What happens if you become unavailable?
Ask it plainly. Companies close, get acquired, change direction, or lose the one person who understood your system.
A supplier who has thought about this has concrete answers: you hold the code, the documentation is written for a developer who has never met them, the platform is open source so anyone can run it, the tests are in the repository, and your accounts are in your own name. A supplier who has not thought about it will reframe the question as a question about trust. It is not. It is a question about arrangements.
Three answers that should end the conversation
Most weak answers are just weak. Three are different in kind.
- "You'll own the code, but it runs on our platform." Then you own a copy of something you cannot operate. The test is whether you can host it elsewhere without permission.
- "We can't give a fixed price, we'll bill as we go", with no discovery phase and no cap. Time and materials is a legitimate model, but it needs a scoping artefact and a budget checkpoint, otherwise the estimate is whatever it ends up being.
- "The warranty is three years", with no exclusions, no response targets and no mention in the contract. A warranty with no boundary is not generous. It is unexamined, and unexamined promises are the ones that get reinterpreted under pressure.
How to use this list
Send it, in writing, to every supplier on your shortlist, and ask for written answers. This does two things. It gets you comparable answers instead of comparable sales conversations. And it tells you how each supplier behaves when asked to commit in writing, which is more predictive of the next twelve months than anything in the proposal.
If you would like our answers, they are mostly already published: what ownership means here, what the warranty covers and excludes, how pricing and milestones work, and what happens after the warranty ends. Anything not covered there, ask us and we will answer it in writing.