← Blog/Process··9 min read

12 Real Questions to Ask a Web Agency Before Signing (2026)

The 12 questions that surface the real tech stack, ownership terms, and post-launch reality before you sign — written by an Australian studio, for AU founders.

G
Written by
Graham Sissons · Founder, Pryce Digital

The pre-signing conversation with a web agency tends to follow a predictable script. Timeline, budget, deliverables, references. The agency answers smoothly, the founder feels reassured, the contract gets signed, and six weeks into the build it becomes apparent that the agency and the client had different mental pictures of the same project.

The questions below are the ones that surface the gap before the contract gets signed. I've structured them so each question reveals something specific about the agency's approach — not because there's only one right answer, but because the agency's answer tells you whether they've thought about the question or not.

This is the list I'd want a founder I cared about to ask the agency they're about to engage.

Question 1: What's the actual tech stack you're proposing for this project?

The right answer names specific technologies. "We're building a Next.js 16 frontend with Sanity as the CMS, hosted on Vercel, with Cloudflare sitting in front for caching and DDoS protection." That's a concrete proposal.

The wrong answer is vague. "We use modern web technologies." "We pick the right stack for the project." Both of these are placeholders for "we'll figure it out and you won't ask again."

The reason this question matters: the stack determines what's possible, what costs ongoing money, and what's portable if you leave the agency. An agency that won't commit to a stack before signing is reserving the right to change it later in a way that's good for them and not necessarily for you.

Question 2: What's the realistic performance budget for the site?

The right answer has numbers. "LCP under 2 seconds on mobile, INP under 200 milliseconds, total page weight under 800KB, Lighthouse mobile score above 90."

The wrong answer is "we build fast sites" without specifics. Or "performance is a priority for us" — which is a meaningless sentence.

The reason this question matters: performance is the single most measurable quality of a website. An agency that won't commit to performance numbers either doesn't know what they'll achieve or doesn't take performance seriously. Either is a problem.

Question 3: How do you handle the SEO migration if we're replacing an existing site?

The right answer mentions URL audits, 301 redirect maps, metadata preservation, Google Search Console handover, and post-launch monitoring. There's a defined process and it's a costed line item in the proposal.

The wrong answer is "SEO is included" without specifying what that means, or "we'll handle redirects on launch."

The reason this question matters: the typical migration that goes badly loses 30 to 40 percent of organic traffic in the first month, sometimes never fully recovers. The work to prevent that is unglamorous and gets cut from proposals. The agency's answer reveals whether they've costed it properly.

Question 4: Who specifically will be doing the work, and are they employees or contractors?

The right answer names people. "Sarah is the senior developer, she's been with us for four years. Mark is the designer, he's our co-founder. We bring in a copywriter, who's a long-term contractor — her name's Jenna and she's done eight projects with us."

The wrong answer is vague — "our team of developers" — without identifying anyone, or admits to subcontracting through marketplaces or off-shoring to teams the agency doesn't manage directly.

The reason this question matters: the people who do the work determine the quality. An agency that won't name them is hiding either inexperience, high turnover, or subcontracting they don't want you to think about.

Question 5: Show me a project you delivered 12+ months ago. How is it performing today?

The right answer pulls up a real site, shows you the live URL, talks honestly about what's worked and what hasn't, and demonstrates that they have an ongoing relationship with the client.

The wrong answer is portfolio shots from sites that were built two years ago and the agency has no current knowledge of how they're performing. Or worse, sites that no longer exist because the client left and the agency lost the relationship.

The reason this question matters: a site that performs at launch isn't the same as a site that performs after a year. The agency's long-term relationship with their work tells you whether they build to last or build to launch.

Question 6: How do you handle accessibility?

The right answer mentions WCAG 2.2 AA as a baseline, automated testing tools (axe, Pa11y), manual keyboard navigation testing, screen reader testing on at least one assistive technology, and accessibility as a deliverable not an add-on.

The wrong answer is "we follow accessibility best practices" without specifics, or treats accessibility as a compliance checkbox after launch.

The reason this question matters: accessibility is increasingly a legal issue under Australian Disability Discrimination Act compliance, and it's also just the right way to build. An agency that hasn't thought about it concretely will produce a site that's broken for a percentage of your audience.

Question 7: What CMS are you proposing and why?

The right answer has an opinion. "We're proposing Sanity because the editorial workflow matches your team's needs, the cost scales with usage rather than being a fixed monthly fee, and we've configured 20+ Sanity projects so we know its edge cases."

The wrong answer is "we'll use whatever CMS you prefer" or "we always use WordPress" — both of which avoid actually thinking about what fits the project.

The reason this question matters: the CMS choice determines what content editors will spend hours every week interacting with. The wrong CMS makes daily operations painful for years. The agency's reasoning reveals whether they've matched the CMS to your team or just defaulted to their habitual choice.

Question 8: How does the IP assignment work in your standard contract?

The right answer is "we assign all IP in the Deliverables to you upon payment in full, including source code, design files, and proprietary work. We retain our pre-existing component libraries and grant you a perpetual licence to use them as embedded in your project. Here's the specific clause."

The wrong answer is anything that suggests the agency retains ownership, grants you a licence rather than assigns IP, or treats this question as something to be discussed later.

The reason this question matters: the default rule under Australian law is that the contractor owns the IP unless the contract says otherwise. The agency's answer tells you whether the contract gets you what you're paying for or what's good for them.

Question 9: What's the realistic timeline, and what happens if it slips?

The right answer is honest about phases (discovery, design, build, QA, launch), has buffer built in for revisions, and explains what triggers a timeline change. "Our standard timeline for a project this size is 10 weeks. We've built in two weeks of buffer for revisions. If we go beyond that because of scope changes, we'll quote the additional work explicitly before doing it."

The wrong answer is a fixed timeline with no buffer, or an indefinite timeline with no clear endpoint.

The reason this question matters: timeline slippage is normal in web projects. The agency's planning approach reveals whether slippage will be communicated honestly or hidden until it becomes a crisis.

Question 10: How will I make changes after launch, and what does that cost?

The right answer distinguishes between things the in-house team can do (content updates, blog posts, image swaps via the CMS) and things that need engineering (design changes, new features, integrations). There's a transparent rate for engineering work post-launch.

The wrong answer is "you'll need to come back to us for any changes" — which signals lock-in — or vague hourly rates without commitment.

The reason this question matters: the post-launch maintenance cost is often 2 to 3x the build cost over the site's lifespan. The agency's structure for this period determines whether you can operate independently or become a permanent retainer.

Question 11: What happens to my site if your studio shuts down?

The right answer is uncomfortable but honest. "Your source code is in your own GitHub organisation from day one. Your CMS is in your own account. Your hosting is in your own Vercel account. If we shut down tomorrow, you can hire any competent developer to continue the work. We've thought about this because we want clients to feel comfortable that they're not dependent on our continued existence."

The wrong answer is hand-wavy or treats this as unlikely. "We've been around for 12 years, we're not going anywhere." Maybe true, maybe not — and not the point.

The reason this question matters: agency mortality is real. Studios fail, get acquired, pivot, or lose key staff. An agency that's structured the work so that you can continue without them is an agency that's prioritising your interests over lock-in.

Question 12: What's one thing about this project you'd push back on if I asked for it?

The right answer involves the agency telling you something they'd disagree with you about. "If you asked us to build this in WordPress because it's cheaper, we'd push back because the maintenance cost and performance ceiling don't fit your goals." Or: "If you asked for a Cool Splash Animation on the homepage, we'd push back because it hurts the load time you've told us matters."

The wrong answer is "we'd build whatever you want" or "we agree with the brief you've given us." Both are signals of an agency that won't tell you when you're making a mistake.

The reason this question matters: you're hiring expertise. The agency's willingness to push back on you reveals whether they have opinions worth paying for or whether they're going to deliver exactly what you said even when you're wrong.

What the answers tell you in aggregate

Twelve questions is enough to spot whether the agency is thinking carefully or selling a generic service. The pattern that emerges:

  • Good agencies give specific, opinionated, sometimes uncomfortable answers. They name technologies, name people, commit to numbers, push back on bad ideas.
  • Average agencies give competent but generic answers. They tick the boxes, don't commit to specifics, mostly avoid pushing back.
  • Bad agencies give vague, defensive answers that reserve the right to change the project later. They avoid commitments, name no specifics, treat hard questions as inappropriate.

The fee a good agency charges is meaningfully higher than what an average agency charges. That gap is usually justified by the answers above. The cost of working with an agency that gives bad answers is bigger than the saving on the engagement fee.

The honest bottom line

A web project costs $8,000 to $80,000 for most Australian businesses. The questions above take 45 minutes to ask and answer. The cost of asking them is zero. The cost of not asking them is sometimes the entire project budget.

If you're about to sign a web agency contract and you've gone through these twelve questions, the agency's answers tell you whether you're making the right call. If the answers are a mix of strong and weak, that's also useful information — the agency is competent but might need pushback on specific scopes.

A useful adjacent move: if any of the agencies you're talking to have shipped a public portfolio site, run a free audit on one of their builds. The report shows you the rendered performance, the SEO surface, and the accessibility score for what they actually delivered — which is a more honest answer to "how good are you?" than anything they put in the proposal. Question 13, really, but it doesn't take 45 minutes.

END OF POST

Want this for your business?

Get a free instant audit of your current site, or book a 20-minute call to talk through what you're building. No sales pitch.

Free auditBook a call
Or email studio@prycedigital.com
Keep reading
Founder Website: DIY, Hire, or Wait? The Real FrameworkProcessContact Form Abandonment: 3 Fields to Delete (2026)ProcessOne Studio for Brand and Web? 6 Signals to Decide (2026)Process
Explore our services
Custom Web Design Melbourne — hand-coded sites built from scratchWebsite Development for Small Business — the full breakdownWeb Design Melbourne — why local matters
← Back to blog indexFree audit