Most bad agency experiences are predictable. The problems that cause projects to overrun, relationships to break down and websites to underperform commercially are almost always visible in the sales and proposal process, before any work begins. The difficulty is that businesses evaluating agencies are often looking at the wrong signals. A compelling pitch, a polished portfolio and an enthusiastic senior team member in the first meeting are not predictive of project quality. They are predictive of a good sales process, which is a different thing.
The signals that actually predict project quality are more specific and less glamorous. They require looking at how the agency approaches the work, not how it presents itself.
The agency that quotes before it understands
A website agency that provides a detailed quote within 24 to 48 hours of an initial conversation has not understood the project. It has applied a pricing template. This is a reliable early signal that the relationship will be more transactional than strategic.
Understanding a project brief properly takes time. It requires asking about the commercial objectives the site needs to serve, the existing performance data, the content situation, the technical dependencies, the team that will manage the site after launch, and the timeline constraints that will affect scope decisions. An agency that skips these conversations to provide a quick number is telling you that it is going to deliver a product to a specification, not work on a problem with you.
The alternative is an agency that asks more questions before quoting than seems necessary, that pushes back on vague parts of the brief, and that takes a week or more to produce a proposal. The proposal that comes from this process is typically more accurate, more specifically tailored to the actual problem, and less likely to explode with change requests once the project starts.
Senior at pitch, junior on the project
This pattern is sufficiently common in the NZ agency market to be worth naming explicitly. The director or senior lead who runs the pitch and earns the business is not the person who builds the site. Once the contract is signed, the project is handed to a more junior team member, sometimes with limited supervision. The senior person reappears at milestone reviews.
Asking directly about who will work on the project day to day, and what their experience with similar projects looks like, is not rude. It is the correct question. An agency that deflects or answers vaguely is signalling that the question is an uncomfortable one.
Looking at the portfolio with this in mind is also useful. If the work in a portfolio is consistently strong but the team the agency is assigning to your project is not the team that produced that work, the portfolio is predictive of the agency's best capability, not the capability you are likely to receive.
Portfolios without performance data
A strong design portfolio is the baseline for any serious web agency. It is not sufficient evidence that an agency's work produces commercial results. Design quality and commercial performance are correlated but not identical, and in the NZ market there are agencies whose work looks excellent and underperforms consistently.
The question to ask is: can you share any data on the commercial performance of recent projects? Conversion rate improvements, organic traffic growth, enquiry volume changes. Agencies that have this data and are proud of their work share it readily. Agencies that do not have it, or are not accustomed to measuring it, respond to the question with some version of "we don't have access to client analytics after handover." This is itself informative.
An agency that does not routinely review its work against commercial performance metrics is not a performance-oriented agency. It may be a very good design agency. These are different things, and which one you need depends on what the website is for.
The contract that doesn't specify ownership
Website projects involve the creation of design assets, code, copywriting and CMS content. The ownership of these assets after the project ends varies considerably across agencies and is governed by whatever the contract says. Many NZ agency contracts are vague on this point, which creates problems when the relationship ends.
The specific questions to get answers to in writing before signing: who owns the design files, and in what format are they delivered? Who owns the code repository, and what are the conditions for accessing it? If the site is built on the agency's Webflow or other platform account, does ownership transfer on project completion? Who owns the domain and hosting configuration?
An agency that is unwilling to specify these terms clearly is either not thinking about the end of the project or is creating a dependency that benefits the agency at the expense of the client. Both are bad signs.
The typical example in the NZ market is a site built on a Webflow account that the agency holds. The client is not the workspace owner and cannot access or transfer the site without the agency's cooperation. When the relationship ends badly, this creates significant leverage for the agency. A contract that specifies transfer of workspace ownership to the client on project completion eliminates this problem before it starts.
No structured post-launch plan
A website launch is not a project completion. It is the point at which the site starts being tested against real visitors and real traffic, and the point at which most of the performance-related issues emerge. The three to four weeks after launch are typically when the most commercially impactful improvements are identified and made.
An agency with no structured post-launch plan is an agency that considers the project over at handover. The client gets the site, the agency considers the work done, and any issues that emerge after launch are treated as new work or support requests rather than part of the original project.
The opposite of this is an agency that builds a post-launch period into the project scope: a defined window after launch during which performance is monitored, conversion data is reviewed, fixes are made, and the site is confirmed to be doing what it was designed to do. This is not optional from a commercial standpoint. It is the difference between a project that ends at delivery and a project that ends when the site is performing.
The agency that only works in one direction
When an agency tells you what the solution is before it has understood the problem, that is a red flag regardless of how confident the delivery sounds. An agency that leads with "we use Webflow for everything" before asking about your business's specific needs is an agency that is applying a preferred solution rather than finding the right one. Similarly, an agency that leads with WordPress, or Shopify, or any platform preference before engaging with the brief, is prioritising its own expertise and toolset over the client's actual requirements.
The right platform for a given project depends on the business's needs, the team that will manage the site, the technical integrations required, the traffic volumes anticipated, and the commercial purpose of the site. An agency with a genuine opinion about platform selection should be able to explain why a specific platform is appropriate for a specific brief. An agency that applies the same platform to every brief regardless of fit is optimising for its own delivery efficiency.
Vague timelines with no accountability structure
Website projects almost always take longer than expected. The agencies that deliver on time consistently are not the ones with the best intentions. They are the ones with a project management structure that tracks scope changes, communicates delays early, and has a contractual basis for timeline accountability.
An agency that provides a launch date without explaining what assumptions that date depends on is not project managing. It is guessing. When those assumptions prove wrong, requirements change, client feedback takes longer than planned, integrations are more complex than expected, the date slips and the explanation is that the project was more complex than anticipated.
The alternative is a project plan that shows the dependencies, identifies the client's obligations (feedback turnaround times, content delivery, approval stages) and specifies what happens to the timeline when those obligations are not met. This is not bureaucracy. It is honesty about how projects actually work.
The timeline question to ask in the proposal process is: what are the most common reasons projects with this scope slip, and how does your process handle those situations? An agency that answers this specifically is an agency that has thought about the problem and has a response. An agency that says "we don't really have scope creep" is an agency that either does not track it or has not been honest with you about past projects.
What good looks like
The agencies that deliver well tend to share a pattern: they ask more questions before they quote, they are specific about who will be doing the work, they can show performance data alongside design portfolios, they have clear contracts about ownership, and they have a structured post-launch plan. These are not exceptional qualities. They are the baseline for a competent professional practice.
They are also not the qualities that make an agency's pitch feel exciting or its portfolio look impressive. The most compelling agency pitch does not always come from the most capable or reliable partner. Evaluating agencies on the signals that predict project quality rather than presentation quality requires asking different questions and being willing to wait longer for a more considered proposal.
For NZ businesses that have had difficult agency experiences in the past, the diagnostic is almost always that the red flags were visible in the pitch process and were either missed or rationalised away. The way to avoid a repeat is not to find a more trustworthy agency. It is to know what to look for.
