Find your perfect development agency: here’s what to look for

Just about every client-side marketer I’ve ever spoken with has a story about “being burned” in some way by a digital or web agency. In this article, I’ll be sharing what I believe to be the pillars of an ideal client-developer relationship so that doesn’t happen to you.

Poor agencies have some typical characteristics.
A lack of reliability. Missed deadlines. Unexpected costs. Arguments about scope. Slow or poor responses. Hacked or crashing sites. Buggy products. Missing functionality. Push-back and bad attitudes from so-called ‘gurus’.

When you enjoy a good working relationship it can really highlight how bad some previous experiences have been. When the agency and client are on the same page, goals become more achievable and hurdles shrink. Communication is clear and each party understands the other. Organic collaboration means that an ultimately complex relationship doesn’t feel complex at all.

Attitude is really about the place an individual chooses to “come from” in their thoughts, feelings and beliefs.

A good attitude is helpful, positive, friendly, reliable, solution-focused, dedicated, honest and transparent. A bad attitude is arrogant, impatient, lazy, egotistical, vague and petty.

How do you detect a bad attitude before it’s too late? Warning signs include:

• Unclear pricing: Quoting can be a complex task, but red flags are raised when a dev agency can’t answer basic questions regarding pricing.
• They’re condescending: If your agency seems dismissive, or doesn’t listen or treat you as an equal or in early meetings, it doesn’t bode well for the relationship.
• A lack of accountability: It’s human to make mistakes, and good agencies own up to them. Poor agencies respond with defensiveness and buck-passing, indicating the organisation has underlying problems.
• A focus on problems over solutions: You hit a roadblock – you desperately need a new feature, but it wasn’t covered in the original scope. A problem-oriented agency says “it can’t be done.” A solution-oriented agency says “leave it with us.”
• Unreliable and unprofessional: Relationships are built on trust. Unavailable, unresponsive, imprecise, disorganised, vague and non-committal agencies are more trouble than they’re worth.

Enough of the deal-breakers – what about the deal-makers? Traits common to the very best agencies include:

• Great communication: The best agencies begin by listening, then ask intelligent, probing questions. They delve into your needs and challenges and offer a considered response. They are clear, honest and available.
• Values-driven: The best agencies can clearly articulate why they do what they do, which offers insight into their attitude and operating style. And if an agency says they are defined by things like honesty, integrity and quality, you can hold them to it.
• Adaptable and solution-oriented: Agencies with these qualities are a help, not a hindrance. New challenges don’t overwhelm – they excite.
• Talented and professional: Being a ‘professional’ developer is about offering a sense of all-round quality – in communication, online presence, attention to detail, reliability, clients and portfolio.
• A great attitude all but guarantees a positive, productive, and even fun working environment. The reverse is true for a bad attitude, which can be made all the worse if you’ve locked yourself into a contract.

To begin with, dip your toe in the water if you can. Ask for a trial period, and get the agency to prove themselves before you lock yourself in.

Set and manage expectations. I’ve been told I bang on about this point – it’s the account manager in me – but throughout my career I’ve seen that when expectations differ between parties, neither are met. When expectations are aligned, issues are avoided and relationships thrive.

Having sat through countless new business meetings, I’ve found that the scene for the relationship is set early. In a client-developer relationship there are plenty of expectations to get right, so ensuring everyone is singing from the same hymn sheet is critical.

Before talking to an agency, develop a rough budget. In my view an agency is within its rights to turn down a tender invitation if no budget is outlined.

There are exceptions, like when you have absolutely no idea what a project will cost, or you need to get a budget approved internally. But development is next to impossible to scope without having a rough idea of budget – it’s very difficult to tailor a best-fit, value-driven solution without a point of reference. It’s like telling a builder ‘I want a house!’ without sharing how much you’re willing to spend.
Quality agencies may feel like you’re just shopping for the lowest price, and don’t care about the value they offer.

An agency can feel like they’re being milked of thoughts and expertise with no guarantee of compensation, or that a decision has been made and they’re just being used as a quote comparison.

Offering a budget – any budget – starts the relationship off on the right foot. It makes an agency feel respected, and shows you to be an open and transparent client. If the budget is too low, a good agency will be able to substantiate an adjustment to your expectations.

If you have no idea on cost, tell the agency and ask for a ballpark figure. They can then develop a range of options and top-line considerations without too much effort. Shop around, get ballparks from other providers, then begin to refine your requirements, the brief and the RFQ.

All businesses juggle priorities, shifting and reorganising where necessary. Agencies juggle multi-member teams across projects at various stages of completion, which means priorities must continually shift.

What is your deadline for the project to be live? If you don’t have one, set one. Deadlines are a great thing – they hold parties accountable and keep wheels in motion. Bring your deadline forward as far as is reasonable, as this creates a handy buffer (which makes you look awesome if you deliver early.)

Remember that reviews and approvals need to happen on both the client and developer sides. These can be difficult to factor into your timeline. Estimate the time required, then add a buffer, and be aware that a dev team can’t sit around waiting for your approval – they’ll get scheduled onto something else, pushing your work down the queue.

Everyone needs enough time to get things done, so make reasonable plans and build in contingency. Unrealistic timelines – whether from an impatient client or an overpromising agency – inevitably lead to disappointment.

‘Scope’, AKA specification, proposal or statement of work, describes what the developers will build. If scope isn’t based on clearly defined requirements, objectives and outcomes, it can be the catalyst for endless problems.

Let’s say that based on client correspondence, a developer proposal includes a ‘Calendar’. The only detail provided is ‘setup and configuration’. The price looks reasonable. The project goes through design, build and testing before it’s delivered for review. “It looks good,” the client says, “but why can’t I make a calendar booking? Why can’t I see detail on each calendar event? Why is there no share button?”

The project is almost live, but the parties find themselves arguing over its scope. It turns into a he-said, she-said – the developer believes they’ve done what was asked, the client believes otherwise, there’s no proof for either statement, and all hours allocated to development have been exhausted.

While it can be tough to capture scope definitively, here are a few practical methods:

• The agency outlines high-level ‘out of scope’ assumptions.
• The dev keeps a close eye on wireframes and designs.
• Go into as much specification detail as possible. How should each feature function? What user story are you satisfying? Ask questions, define parameters.
• Incorporate Agile methodology.
• Identify things you can’t specify and decide how these will be tackled.
• Identify areas that represent the major budget and timeline risk, and create contingencies.
• Keep a budget for ‘just in case’ situations.
• Create clear steps to agree and approve a change request, including escalation points.
• Ensure the development time against features is capped (and it’s in writing)

With agency priorities constantly shifting, the best will have clear processes around resource scheduling. Others, meanwhile, will lack process and instead bounce from client to client based on who is screaming the loudest.

Both agency and client should agree on and adhere to a set of rules, such as:

• Weekly scheduling.
• X lead time before work commences.
• Priority rates apply to those who jump the queue.

It might sound enticing to go with an agency who is willing to drop everything for you, but in reality this indicates a lack of process and resource management. Beware that you could soon go from the ‘drop everything’ client to the client whose work is dropped.

Setting payment expectations is as simple as ensuring the terms are clear for both parties. If the agency might face delays due to lengthy procurement approvals – the client should let them know so they can plan for it. Typically there will be a deposit invoice, progress payments and a final payment prior to the go-live and after the site-to-live approval (and completion of UAT.)

There should be a written agreement regarding what happens after a project goes live. Often agencies are unable to provide guarantees due to shifting tech landscapes and ‘technical debt’. However, almost all tech products demand some form of maintenance however, so where an SLA is offered, ensure it is clear about inclusions and exclusions. This goes for iterative products as well – the terms should be clear as to “what’s in” and “what’s out”.

Identify project risks and how they can be mitigated. At project inception we usually include a table with client- and project-specific risks, rates of likelihood and impact, and the risk mitigation action we’ll take.

Identify all individuals within the project and outline their roles:

• Who are the stakeholders and project sponsors?
• Who signs off on deliverables?
• Who manages invoice payments?
• Who are the agency and client project leads?
• Who leads the delivery teams?
• Who is the first point of contact?
• Who is the point of escalation for disputes/disagreements?

All engagements must begin by defining the relevant terms and conditions. While Ts and Cs might constitute ‘fine print’, they can’t be buried in it – the agency should clearly outline the most important terms, including:

• Deliverables and services
• Exclusions
• Client responsibilities
• Acceptance criteria
• Change requests/author corrections
• Intellectual property
• Payment terms
• Term and termination
• Liability
• Confidentiality and non-compete clauses.

A solid rule is to always seek legal advice for contracts associated with B2B engagements, as they’re inevitably filled with legalese, which is a language unto itself.

While the considerations listed above are the most notable examples of expectation-setting, others include:

• Goals and objectives
• Project phases and milestones
• Systems and processes
• Communications
• Deployment processes

The agency and client need to gain a mutual understanding of all of these aspects before work kicks off. If you don’t, there’ll be stormy seas ahead.

What does great communication look like? It’s clear, concise, honest, relevant and personable – fun isn’t just allowed, it’s encouraged!

The following strategies lead to better client-developer communication:

• Limit your channels: Avoid chatting via combination of phone, email, DM, telegram, carrier pigeon, semaphore and banner plane. Discuss and agree on how you’ll communicate, with the aim of centralising comms as much as possible.
• Lean on tech: A great way to consolidate communication is through a platform like Slack, which also avoids scouring through endless email chains.
• Schedule meetings: Before booking a meeting, ask yourself: Will an email suffice? Does every invitee truly need to be there? Is Zoom as good as in-person? Schedule meetings only as often as genuinely necessary. Consolidate feedback – sending piecemeal updates can drive people crazy.
• Streamline meetings: Develop and agree upon an agenda. Strictly limit your meeting to the time allocated – discuss agenda items, make decisions, allocate responsibility and move on. Post-meeting, share minutes and agreed-upon actions.
• Balance written and verbal: Sometimes it’s important to capture things in writing. Other times it’s best to make a quick call. Beware the keyboard warrior who avoids phone calls and meetings.
• Capture key comms: Use a project charter or digital repository to capture key documents and information.

Dev teams must understand both the wider picture of what their client is looking to achieve, and the granular detail needed to execute the deliverables. They should be capable of translating their work into layman’s terms, to give the client an understanding of the whats, whys and hows.

There’s a balance to be struck. The dev team needs to intuitively know what will and won’t go over a client’s head, and how much detail they need to make an informed decision.

To this end the best dev teams are capable of neatly articulating the key considerations and implications of a proposed solution, condensing the complex interdependencies of technologies and their functionalities into simple terms.

There are also some things that even the greatest developers simply don’t know. Both the client and the agency need to show trust in the dev team from time to time, and give them some leeway.

This leeway extends to the fruits of your project. If you are prescriptive you’ll place hard limits on outcomes. A good technical team will challenge your thinking and open up a wealth of possibilities in the process.

Finally, good dev teams proactively provide updates. This is a common sticking point, with clients and agencies alike finding themselves constantly chasing tails. Good teams do this out of habit, getting in touch even when there’s no real update to share.

Digital product, web or application development is a process. High level, phases typically include:

> Scoping & Discovery

> Strategy, Research, Planning

> IA & Navigation

> Creative & UX Design

> Development

> QA & Test

> User Acceptance Testing

> Training & Hand over

> Support, Maintenance, Warranty

Note that this is different to an agile/product development process, which would feature market research, testing, MVP, metrics, benchmarks, etc.

Input from technical resources is needed, at varying levels, during every single stage – even in strategy and planning, when a developer should review functional specifications (given they’re the ones building.)

Work with your agency to understand their process, and watch out for stakeholders on either side of the relationship who fail to follow it. Some common process pitfalls include:

• A lack of planning that results in poor or misaligned execution.
• Missing designs, or bringing designs in late, increasing development and testing scope.
• A lack of briefing or review, leading to misunderstandings of scope and incorrect implementation.
• A lack of testing, leading to bugs and technical issues, differences between design and product, and more rounds of reviews.
• A lack of user acceptance testing (UAT) resulting in incomplete or problematic projects going live.
  A client prematurely offering go-live approval, signalling that the product is complete, but not understanding that work beyond this point may be considered billable.

Expertise can be generalist or ultra-niche. A senior software engineer can have limited front-end skills, and a WordPress pro might only bring general PHP knowledge. An agency must therefore align their talent resources with the right client projects.

Developers don’t need to be an agency’s ‘everything’, but they do need to be an agency’s ‘something’. The skills found within an agency should fit that agency’s needs.

There are also some standards which can’t be compromised on, such as best code practices. Cutting talent corners here can leave a trail of destruction that affects the client and agency alike. While the best developers will bring broad and deep technical knowledge and high-level soft skills, all will have their own strengths and weaknesses.

The most important thing is to find someone capable of tackling the project or task, whatever level of professional that might mean. That doesn’t always mean the best: why use a high-priced expert when a junior developer is more than capable yet half the price?

In my view, a healthy client-developer relationship features five key ingredients. Combine the right attitude, clear expectations, good communication, established processes and the necessary expertise, and you’ll be ready to bake a delicious project cake.