Thirteen Questions to Ask a Web Vendor Before Signing

You cannot audit a portfolio, and you can audit whether a vendor hands you a repository URL when you ask for one.

That difference is the whole method. Thirteen questions, each with a good answer that produces something you can open: a link, a list, a login, a written procedure. Eight of them apply to any build, whatever it is built with, and five more apply only when the pitch is a page builder.

Ask them before you commit, including of me.

Eight questions apply to any build, whatever the vendor builds with

All eight test one thing: whether there is a maintenance model, meaning a named and written answer to who keeps the site alive after launch. It is the same question the platform choice itself turns on, asked again of the person quoting for the work. A vendor who has one answers quickly and a little boringly. A vendor who does not answers warmly.

1. Where will the code live, and in whose name?
2. What will you hand over at launch, and in what form?
3. How many plugins will the site carry, which ones, and who maintains each?
4. If you are unavailable for a stretch, how does the site keep running?
5. Is there a staging site, and does every update go through it?
6. What is the rollback procedure, and how long does it take?
7. What are the launch targets for performance and structured data?
8. Can we end the maintenance arrangement and keep everything?

Every one of them asks about accounts, access and procedure, which is the layer you can verify yourself without a technical adviser sitting beside you. If you want an agreement drafted around any of the answers, that is a conversation for a lawyer.

Two of the eight you can partly pre-check before a vendor replies. The maintenance signals the plugin directory publishes are public, and staging is standard engineering practice rather than an upsell invented for your proposal.

Checks like that are worth more than the signals buyers usually go on. Professional services get chosen on relevance, reputation and referral, per buyer research on how professional services are actually chosen, and none of those three tells you anything about month nine.

A good answer hands you an artefact, a weak answer hands you a feeling

Each of the eight has a good answer that produces an object: a repository URL, a named list, a written procedure, a login. Objects can be checked later, by you or by whoever you bring in next. Reassurance cannot.

Question 2 is the clearest case. What a written definition of finished contains is agreed before work starts rather than judged on the last day, and research linking documentation quality to whether software can be maintained by someone else is why the form of the handover matters as much as the fact of one.

The question to ask	What a good answer hands you	What a weak answer sounds like
Ask where the code will live and in whose name.	You get a repository URL and an invitation to an account you already control.	The vendor says the files are safe on their server and offers to send a copy.
Ask what will be handed over at launch, and in what form.	You get a list of deliverables agreed before work starts, naming the repository and the documentation.	The vendor says the handover is whatever you need on the day.
Ask how many plugins the site will carry, and who maintains each.	You get a named list with each plugin’s maintainer beside it, so you can read its update history.	The vendor says they only use plugins they trust and will keep the list lean.
Ask how the site keeps running during a stretch when the vendor is unavailable.	You get a named second contact and a written note of where the credentials live.	The vendor says they are always reachable, which answers a different question.
Ask whether there is a staging site and whether every update goes through it.	You get a staging URL you can log into and a list of what gets rehearsed there.	The vendor says small changes go straight to the live site because they are careful.
Ask what the rollback procedure is and how long it takes.	You get a written procedure with its duration stated, so a bad release becomes a scheduled fix rather than an outage.	The vendor says a backup runs nightly, which names a file and skips the steps.
Ask what the launch targets are for performance and structured data.	You get named thresholds and the tool that measures them, so launch quality is something you verify.	The vendor promises the site will be fast and search friendly.
Ask whether you can end the maintenance arrangement and keep everything.	You get a plain description of what transfers on the last day, including the documentation.	The vendor treats the question as a sign of bad faith.

Question 7 is the one buyers routinely leave vague, and the easiest of the eight to make concrete. The publicly defined performance thresholds exist, the Organization type a services site needs is a published specification, and what a search visibility baseline is measuring belongs in a scope alongside what a site architecture plan should cover.

The weak answers all share one structure. Each swaps a procedure for the vendor’s character, and character does not survive a holiday, a bad release on a Friday, or the developer who knew the site leaving for another job.

Question 4 is where that shows up fastest. It is the supervision argument journey position 17, AI SEO Services: Six Flex Points and Who Decides, makes about a workflow, asked here of a supplier instead. The answer worth having names a second person and says where the credentials live, and any answer that cannot be turned into a file is the answer that ends the conversation.

The artefact test

Decide in advance what a good answer would produce, then ask and see whether it arrives. You are not judging whether the vendor sounds competent, which you cannot assess, and you are judging whether the artefact exists, which you can.

Page builder pitches earn five more questions, and a good builder shop answers all five

Ask these five when the design will live inside a page builder plugin. That path keeps your content and design layers in the same place, which is what makes it quick to work in, and each of the five asks what that arrangement costs you later.

1. Which builder, which version, and what happened to your client sites at the last major release?
2. How many add-on plugins will this design need beyond the builder, and from how many vendors?
3. If we deactivate the builder in three years, what is left of our pages?
4. Who watches for security disclosures in the builder and its add-ons, and how quickly are patches applied?
5. What are the recurring licence commitments, and which of them are required for the site to keep working?

The question to ask	What a good answer hands you	What a weak answer sounds like
Ask which builder and which version, and what happened at the last major release.	You get the product name, the version in use, and an account of what needed fixing afterwards.	The vendor says upgrades are routine and nothing has ever gone wrong.
Ask how many add-on plugins the design needs, and from how many separate vendors.	You get a counted list naming each add-on’s supplier, so you know how many companies you depend on.	The vendor says they add a few extras as needed.
Ask what is left of your pages if the builder is deactivated in three years.	You get an honest description of the content without the plugin, and a demonstration on staging.	The vendor says you would never want to deactivate it.
Ask who watches for security disclosures in the builder and its add-ons.	You get a named person or service, a stated response window, and a log of past updates.	The vendor says updates are handled automatically, which describes a setting.
Ask which recurring licences the site needs to keep working, and which are optional.	You get a list separating the licences the site depends on from the ones that add convenience.	The vendor says licensing is all included, without saying whose account holds it.

A shop that answers all five of these well is a safer choice than a custom shop that cannot answer the first eight.

Question 11 decides the rest of them. If your content stays in portable core blocks, leaving the builder later is a redesign. If it does not, leaving is a rebuild, and that difference lands years after the decision that created it.

Where the code lives predicts the answers to the other twelve

Ask question 1 first, and listen to the shape of the answer rather than its warmth.

A vendor who keeps your site in version control under an account you own has already been forced to solve much of the rest. Version control turns a rollback into a procedure, gives a second person something to pick up, and makes a handover a transfer rather than a favour.

A vendor who keeps your site only on their own machine has nothing to hand over, so questions 2, 6 and 8 can only be answered with assurances. One working practice produces the artefacts the other twelve ask for, and its absence produces none of them, which is why the first answer tells you roughly how the rest of the conversation will go.

Send the eight by email and count how many replies carry an attachment

Send the eight general questions by email before the second meeting, then count how many come back with a link or a document attached. That count predicts the engagement better than the proposal does.

A meeting lets a vendor perform an answer. An email makes them produce one, because the artefact either exists already or has to be invented on the spot.

Three attachments and a straight sentence about the other five is a good result. Eight paragraphs of reassurance and nothing attached is also a result, and it is the one worth acting on before money changes hands. If you are unsure which launch targets in question 7 matter for your site, a technical checklist ordered by severity ranks them.

Eighteen steps brought you here, and some of them stay yours whichever way you go

Positions 1 to 4 settle what you built: where the design lives, what an AI assisted theme leaves for a person to decide, the structure a generated build already chose for you, and what changing direction costs. Positions 5 to 10 write the pages that structure called for, money pages before blog.

Position 11, Editing an AI First Draft to Match Search Intent, is the single return visit to SEO, because a drafted page answers a topic while a searcher asked a query. Positions 12 to 17 turn found into cited, from what answer engines reward through to where the human still decides.

Somewhere in that sequence the honest answer is that this is not your job, and hiring the build out is a reasonable response to reaching it.

What hiring it out does not hand over is the judgement in positions 5 to 10, because nobody outside your business can say what your service pages promise. Journey position 10 in the Content lane, Website Content Writer: The Point You Hand It Over, draws that line, and who owns the content process after launch makes the same argument about production.

Whether to hire any of it out at your stage is its own question, and whether SEO is worth it yet is the honest version of it.

Book a free diagnosis

If you want a second opinion on the answers you get, book a free diagnosis and bring the proposal with you. I will read the replies against the thirteen, tell you which produced an artefact and which produced a sentence, and say where I think the risk sits before you sign.

Book your free diagnosis

Ask me the same thirteen

Put the thirteen to me as well. Ask where the code will live and in whose name, what arrives at launch and in what form, how the site keeps running when I am not available, and what you keep on the day you stop.

I would be paid to do this work, which is a reason to run the same test on me rather than a reason to exempt me from it. The services I offer answer a different question, and what you publish once the site is live stays yours either way.

If what comes back is not an artefact, you have learned the same thing you would have learned about anyone else, before signing rather than in month nine.

Frequently Asked Questions

What questions should I ask a designer?

Ask thirteen, and judge each answer by what it produces rather than how it sounds. Eight apply to any build: where the code lives, what is handed over at launch, which plugins and who maintains them, continuity, staging, rollback, launch targets, and what you keep if you leave. Five more apply when the pitch is a page builder.

Who owns my website when someone else builds it?

Ownership becomes real at the level of accounts and access. Check that the domain registration, the hosting account, the code repository and the analytics property all sit in your organisation’s name, under a login you control rather than a shared one. What an agreement should say about ownership is a question for your own lawyer.

What should a design contract include?

Ask for the deliverables that survive the relationship: repository access, a named plugin list, handover documentation, a rollback procedure, and a written definition of finished. Those five are the ones you can check yourself before you commit. Drafting the agreement itself belongs with a lawyer, and I do not offer a view on clauses.

What makes a designer good?

Good designers produce artefacts on request. Ask for a repository URL, a staging login, a plugin list or a rollback procedure, and a good one sends them within a day because all four already exist. Portfolio work shows taste, which genuinely matters, and says nothing about whether the site is maintainable in month nine.

Is there a way to figure out who built a website?

Page source and browser extensions will usually name the platform, the theme, and often the page builder a site runs on, which makes useful due diligence on a vendor’s own examples. What the check cannot tell you is who wrote the code, who maintains it today, or whether the client holds the accounts.

Can I hire someone to manage my website?

Yes, and an ongoing maintenance arrangement is normal. The thing to settle at signing is who holds the maintenance model afterwards: who applies updates, who watches for security disclosures, who provides named cover when your main contact is away, and what transfers to you the day the arrangement ends.

Continue Reading:

Previously in this series

• AI SEO Services: Six Flex Points and Who Decides, the six flex points an assisted workflow hands back, which is what these thirteen questions test a vendor on.

From the library

• Is SEO Worth It for a Startup? When to Invest and When to Wait, whether SEO belongs in this vendor conversation yet, or should wait.
• Technical SEO Checklist for Founders, by Severity, the severity-ranked issues a vendor’s platform choice will make easy or hard to fix.
• Content That Converts Readers Into Customers, the funnel structure your vendor’s templates need to support once traffic arrives.

Explore TDM Insights Categories

• SEO
• AEO
• Content
• Case Notes