Pre-signing checklist: 26 questions before you commit to a web project

Twenty-six questions to answer before signing for a website, software or ongoing digital work, grouped by what each protects.

3 minread 747words last updated

How to use it

Send the list to each supplier with your brief and ask for answers in writing alongside the proposal. Score the answers with the proposal. Before signing, confirm that every answer you relied on is reflected in the contract. A blank is a risk to resolve, not a detail for later.

Scope and price

QuestionWhat a good answer contains
1. What exactly is included, by deliverable?A specific list, grouped by stage
2. What is explicitly not included?A list: content, migration, integrations, training, hosting, support, as applicable
3. What assumptions is the price based on?Content timing, rounds of feedback, existing assets, data state
4. How are changes requested, priced and scheduled?A process or a change budget
5. What is the price, how is it structured, and what triggers each payment?Deposit, milestones tied to deliveries, final at launch
6. What will it cost per month after launch, and in whose accounts?Hosting at provider prices in yours; maintenance as a defined scope
7. What do you need from us, and by when?Decisions, content, access, with dates

Ownership

QuestionWhat a good answer contains
8. Whose name will the domain, DNS and hosting be in?Ours, from day one
9. Where will the code live, and in whose account?A repository in our organisation account; supplier as collaborator
10. When does ownership of the work pass to us?Per milestone for work paid, or on payment, not contingent on the last invoice
11. Which third-party components and licences are included?A list with terms
12. Where will our data be processed and stored, and under what agreement?Regions named; processor agreement provided

Quality and delivery

QuestionWhat a good answer contains
13. How will we see progress before launch?Prototype, previews per change, working stages
14. What is tested, and how?Automated tests, accessibility, performance, security checks, on every change
15. What accessibility and performance thresholds will the result meet at launch?Named standards and measurements, verified at acceptance
16. Who will actually do the work?Named people; a clause about changes
17. What is the timeline, by stage, with our dependencies shown?A staged plan with client dates
18. What warranty applies after launch?Defects covered, period, response times, remedy
19. How long is the acceptance period, and what happens if we do not respond in time?A number of business days, and whether silence counts as approval. In our terms it is 10 to 15 business days after delivery to staging, and work not rejected in writing within it is deemed approved

Running the result

QuestionWhat a good answer contains
20. What documentation will we receive?The set a successor could work from
21. What does maintenance include, at what cadence, with what response times?A scope list, a severity table, a monthly report
22. What is monitored, and who is alerted?Uptime, errors, forms, certificates; a named person
23. How are backups taken and how often are restores tested?Schedule, location, restore test cadence

The relationship’s end

QuestionWhat a good answer contains
24. What is the notice period, in each direction?One to three months
25. What is handed over at the end, in what form, by when, at what cost?Code, documentation, credentials, data; included; within notice
26. Can you show us a hand-over you delivered to a previous client?A document list, anonymised

Written by the CivSec S.M.A.R.T team

We build and run websites, software and AI systems for businesses. We write about what we see in that work, in plain language, and we update articles when things change.

Last checked . Spotted something outdated? Tell us.

Frequently asked questions

Is it not excessive to ask twenty-six questions of a small project?

The answers for a small project are short, and several are the same regardless of size: whose name is the domain in, where does the code live, what happens at exit. A supplier used to working properly answers the list in an hour. The list is not a burden on good suppliers; it is a filter for the others.

What if a supplier will not answer some of them?

Then you have learned which parts of the engagement they have not thought about or do not want to commit to. Ownership, documentation and exit are the usual gaps. Decide whether you can live with the blank; for those three, the answer is usually no.