7 Red Flags to Spot When Hiring a Software Development Agency

Most agency pitches sound the same because most agencies say the same things. They communicate well, they are senior, they are agile, they use AI responsibly. None of that is checkable in a meeting, which is why choosing on the strength of the pitch tends to produce the outcome people describe afterwards as bad luck.

This guide is built on a different question: what can you ask to see? Many claims an agency makes in a pitch should leave an artefact somewhere. A statement of work has acceptance criteria in it. A delivered project has pull requests, test runs and a handover document. An agency that uses AI in delivery has a review step it can describe and show you. Asking for the artefact costs one email and separates a practice from an intention.

Below are seven warning signs, each paired with the behaviour that answers it and the evidence that settles it. The scorecard after them collects the questions into something you can take into a meeting.

What you are buying when production gets cheaper

There is an argument worth borrowing here, from Jared Newman writing in Rex Woodbury’s Digital Native in July 2026. It holds that when machines absorb more of the production work, the scarce human skill becomes judgement: knowing what a correct output looks like and being willing to reject one that is merely plausible. It is an opinion essay rather than a study. It frames the problem usefully; it establishes nothing about what any of this produces in practice.

The buying implication is concrete enough. If part of an agency’s throughput now comes from tools you could licence yourself, throughput is only part of what you are paying for. You are also paying for the judgement that decides what ships, and judgement is visible in what someone rejects. That single idea sits behind most of the questions in this guide, and it is why the strongest question you can ask about AI is what it produced that they threw away.

The green flags that answer each red flag

Each of the seven sections below closes with a green flag: the behaviour that shows an agency is handling what the red flag warns about. Each one also names an artefact you can ask for, so the green flag becomes something you verify rather than something you hope for.

Red flag 1: the “yes” agency that never pushes back

You come to a meeting with a list of features. The agency enthusiastically agrees to everything and is eager to give you a quote. This feels great, and it is a warning sign.

What it signals: a lack of strategic thinking. An agency that immediately agrees to everything is an order-taker. They are focused on closing a deal rather than on the success of your product.

The hidden danger: you are paying for their experience, and their most valuable contribution is using it to challenge your assumptions. A partner asks hard questions: is this the most critical feature for launch, and have we considered the technical risks of this approach? Their job is to protect you from building the wrong product, even when that means disagreeing with you.

The green flag: a partner who asks more questions than they answer in the first meeting, and who is trying to understand your business goals before they talk about code.

Ask to see: a scoping document from a delivered project where the agency recommended cutting or deferring something, and what happened to that recommendation. An agency that has never talked a client out of anything is telling you something about how it sells.

Red flag 2: the price is “too good to be true”

You get a quote dramatically lower than all the others. It is tempting to read that as a win, and it usually means something has been left out.

What it signals: a junior-heavy team, skipped quality assurance, or work passed to third parties you have no relationship with.

The hidden danger: a low initial price leads to higher costs later when it omits review, testing or maintenance. Brittle code is difficult to update, so future features take longer to build. AI code generation can speed up delivery, and generated code still needs engineering oversight. Veracode’s 2025 GenAI Code Security Report found security flaws in 45% of its tested generation tasks. That measures the report’s test set, and price alone does not establish how any particular agency uses AI. Ask who reviews the output, what security checks run, and who is accountable for defects.

The green flag: a detailed breakdown of costs. The agency will not be the cheapest, and it can explain what the difference buys.

Ask to see: the same quote split into build, review, testing and post-launch support. If those lines are missing from the estimate, ask whether they are included elsewhere or excluded; otherwise they can reappear as change requests.

Red flag 3: the “bait-and-switch” team

During the sales process you meet impressive senior leaders and architects. Once the contract is signed, the project is handed to a more junior team.

What it signals: a sales tactic. Their senior talent is allocated to winning work rather than doing it.

The hidden danger: the people who understand the nuances of your vision are not the ones building it, which produces miscommunication, slower progress, and a product that drifts from the brief.

The green flag: ask directly whether the senior people in the room will be on your project day to day. A useful follow-up is how senior people stay involved when AI tools are in the workflow. The substitution is not always one human for another now; sometimes the senior review step quietly becomes a prompt.

Ask to see: named people with their allocation, written into the statement of work, and a commitment about what happens if someone leaves the project. “A senior engineer will be assigned” is not a name.

Red flag 4: they cannot clearly explain their process

You ask how you will work together and get a vague answer about being agile and having lots of calls.

What it signals: no repeatable process. They are improvising.

The hidden danger: a project without a clear process drifts into scope creep and missed deadlines, and you are never certain what is being worked on or whether it matches the goal. There is a 2026 version of this worth listening for: “we use AI to build faster” is not a process. An agency that cannot tell you how AI-generated code is reviewed before it ships, what security testing runs, or who is accountable when something breaks has given you the same vague answer in newer clothes.

The green flag: a partner who can walk you through discovery, design, development cycles and launch, and show how each stage stays visible to you.

Ask to see: the acceptance criteria from a delivered statement of work, redacted. This is the highest-value artefact in the whole list, because acceptance criteria are where a process either becomes specific or stays decorative. Vague criteria are how two parties end a project disagreeing in good faith about whether it was finished.

Red flag 5: the conversation is only about the launch

The agency is focused entirely on building and deploying the first version. Nothing is said about what follows.

What it signals: a transactional mindset that treats your product as a one-off job.

The hidden danger: products evolve after release, and the weeks after launch are when user feedback is most useful. An agency that has not planned for that period is handing you something that starts ageing on day one.

The green flag: a partner who talks about analytics, user testing and how the first version sets up the next, and who treats launch as a starting line.

Ask to see: what support looks like in writing. Response times, who is on call, how defects are separated from new work, and what the arrangement costs. A support conversation that only happens after launch is a negotiation you will enter from a weak position.

Red flag 6: “we’re AI-powered”, with nothing behind it

Many agencies claim to be AI-first, AI-native or AI-powered. Some of those claims are marketing rather than method.

What it signals: AI as a label rather than a practice. The FTC has pursued AI-washing through its Operation AI Comply initiative, targeting companies that overstated what their AI tools did. The same pattern appears in agency positioning.

The hidden danger: you hire them for an AI advantage and get the same general-purpose tools anyone can licence, with no defined process, no quality controls and no senior oversight. The label hides what the work looks like until the project is already in trouble.

The green flag: a specific account of what AI handles, what it does not, and what checks run before that work ships, including where it helps and where it does not.

Ask to see: a case where they rejected AI-generated work, and what made it wrong. This is the question that separates the two kinds of answer, because it cannot be answered from a marketing page. A team that reviews output seriously should be able to explain an example. Without one, you still have no evidence that the review is substantive.

Red flag 7: they cannot tell you who owns the code

Code ownership used to be a straightforward contract question.

What it signals: either they have not thought about it, or they have and would rather not raise it.

The hidden danger: where an agency uses AI tools to generate code, the contract needs to distinguish rights it can transfer from material that may not attract copyright protection. US Copyright Office guidance requires sufficient human authorship, and prompting or reviewing an output alone does not establish it. Human-authored contributions can be protected even when a work also contains AI-generated material. Generated code can also reproduce third-party material carrying its own licence obligations. Ask how the agency records human contributions and checks for that material, and have counsel assess the agreement under the law that applies to your project.

The green flag: specific contract language covering three things: that AI-generated code has been reviewed and modified by human engineers, that IP rights are assigned to you, and that the agency is managing training-data licensing risk.

Ask to see: the assignment clause itself, before you sign, and the list of accounts the project will touch with a note against each saying who will own it. Ownership of the repository is the part people remember. The cloud account, the domain registrar, the error tracker and the analytics property are the ones that turn into a bad month later.

The interview scorecard

The seven flags above tell you what to watch for. This turns them into a set of questions with a checkable answer against each, covering the areas where a disagreement after signing is most expensive.

It carries no scores. A number would suggest the answers have been validated against something, and they have not: what you are recording is what the agency said and what they produced when you asked for the artefact behind it.

SOFTWARE PARTNER INTERVIEW SCORECARD
Vendor: ....................  Date: ............  Interviewer: ............

1. OWNERSHIP OF CODE, DATA AND ACCOUNTS
   Ask ............ Who owns the repository, the cloud accounts, the domain
                    registrar, the analytics and the error tracker, on day one
                    and at the end?
   Evidence ....... The IP assignment clause. A written list of every account
                    the project touches, with an owner against each.
   Credible ....... Accounts created under your organisation from the start,
                    agency granted access. Assignment covers work product and
                    names what it cannot transfer.
   Warning ........ "We'll transfer everything at the end." Ownership discussed
                    only for the repository. No answer on data export.
   Notes .......... .................................................

2. DISCOVERY AND ACCEPTANCE CRITERIA
   Ask ............ How will we agree that a piece of work is finished?
   Evidence ....... Acceptance criteria from a delivered statement of work,
                    redacted. The discovery output from that same project.
   Credible ....... Criteria a third party could test without asking either of
                    us what was meant. A named person who signs off.
   Warning ........ "We'll know it when we see it." Criteria written as
                    feature names. Discovery priced as a formality.
   Notes .......... .................................................

3. HOW AI-ASSISTED WORK IS VERIFIED
   Ask ............ Where does AI sit in your delivery, and what happens to its
                    output before it reaches my repository?
   Evidence ....... A case where they rejected AI-generated work, and why.
                    The review step, named, in their process documentation.
   Credible ....... Specific about what it does and does not handle. A human
                    accountable for the result either way.
   Warning ........ Throughput claims with no review step. No example of
                    anything rejected. Refusal to say whether it is used.
   Notes .......... .................................................

4. RELEASE ACCESS AND DEPLOYMENT
   Ask ............ Who can deploy to production, and can we deploy without you?
   Evidence ....... The deployment runbook. The access list for production.
   Credible ....... Your team can hold production access. Releases are
                    documented well enough for another team to run one.
   Warning ........ Deployment only through their staff or their tooling.
                    No runbook. Credentials held personally rather than by role.
   Notes .......... .................................................

5. QUALITY CHECKS
   Ask ............ What runs automatically before code reaches production?
   Evidence ....... A CI configuration or a test report from a delivered project.
                    A pull request showing review comments.
   Credible ....... Named checks that run on every change. Review by someone
                    other than the author. A stated position on coverage.
   Warning ........ Testing described as a phase rather than a habit.
                    QA that appears only in the final week of the plan.
   Notes .......... .................................................

6. SUPPORT AFTER LAUNCH
   Ask ............ What does support cover, what does it cost, and who answers
                    at 2am?
   Evidence ....... A support agreement from an existing client, redacted.
   Credible ....... Response targets by severity. Defects separated from new
                    work in writing. A named escalation path.
   Warning ........ Support discussed only after launch. Bug fixes and new
                    features billed from the same undefined pool.
   Notes .......... .................................................

7. HANDOVER AND EXIT
   Ask ............ If we part company in a year, what do we have?
   Evidence ....... A handover document from a finished engagement.
   Credible ....... Documentation maintained during the project. A rehearsed
                    or at least written handover. No single person holding
                    knowledge nobody else has.
   Warning ........ Handover treated as a closing task to be scoped later.
                    Discomfort at the question itself.
   Notes .......... .................................................

CROSS-CUTTING: which answers came with an artefact, and which stayed verbal?
   .................................................................

A filled-in example

The example below is illustrative. It is written to show how the scorecard reads once answers are in it, and the vendor and project are invented for that purpose.

Area	What they said	What arrived when asked	Reading
Ownership	”Everything transfers at the end.”	Assignment clause, strong. No account list.	Clause is fine. Accounts unresolved, and that is the part that bites
Acceptance criteria	”We work to a definition of done.”	Redacted criteria from one project, testable	The strongest answer of the seven
AI verification	”Senior review on everything AI touches.”	A rejected authentication approach, with the reasoning	Detailed enough to be credible
Release access	”We handle deploys.”	No runbook offered	Deployment sits with them; ask what it takes to change that
Quality checks	”Full test coverage.”	CI config, tests run on every change, coverage unstated	The evidence shows automated checks; the coverage claim still needs a definition
Support	”We’re always available.”	No agreement, pricing to follow	Verbal only
Handover	”We’d write it all up.”	Nothing from a past engagement	Verbal only

Four of seven answers arrived with an artefact. That is not a score and it does not settle the decision on its own. It tells you where the conversation stopped being checkable, which is where the next meeting should start: accounts, deployment access, support terms and handover, in that order, because each one is cheaper to fix now than after signature.

Compared against a second vendor, the useful comparison is not who sounded better. It is who produced more of what you asked for, and whether the gaps in each case sit in areas you can live with.

If the work is a mobile app

Mobile delivery adds one ownership question that does not appear in web projects, and it is worth adding a line to section 1 rather than running a separate process. Ask who will hold the Apple Developer and Google Play accounts. The safest arrangement is that both are created under your organisation and the agency is invited in, because moving an app between developer accounts later is slower and more procedural than moving a repository, and it can sit on the critical path of a release. Ask the same question about signing certificates and provisioning profiles, and about who holds the store listing assets.

Everything else in the scorecard applies to a mobile build unchanged.

Choosing a partner is choosing a trajectory

Hiring a delivery partner is an investment in what your product becomes. The partner you choose shapes its quality, your speed to market and how much of it you control afterwards.

The green flags in this guide describe how WAYF works. We push back in scoping, price for value, and keep the senior people you meet on the project through delivery. That includes being specific about where AI sits in our process and where human judgement takes over, and treating launch as the point where the next round of work starts. We would rather be asked for the artefacts than believed.

If you are choosing a Payload partner specifically, we publish a shortlist with the evidence behind each agency, including where someone else is the better fit.

The first step here is a conversation with no obligation: book a call and we will go through our process in detail and hear what you are ready to build.

FAQ

1. What are the red flags when hiring a software development agency?

   An agency that agrees to everything without pushing back, a quote dramatically lower than every other quote, a senior team that appears in the sales process and not in delivery, a vague answer about process, a conversation that stops at launch, an 'AI-powered' label with no method behind it, and an inability to say who owns the code.

2. What are the green flags in a software development agency?

   A partner who asks more questions than they answer in the first meeting, gives a detailed breakdown of costs, keeps senior people on the project day to day, can walk you through the whole process from discovery to launch, plans a feedback loop for after launch, explains specifically where AI fits in their work and what checks exist before it ships, and has contract language assigning the IP to you.

3. How do I check an agency instead of trusting the pitch?

   Ask for an artefact rather than a description. A redacted statement of work with its acceptance criteria, a pull request from a delivered project, a test report, a runbook, a handover document. Many pitch claims should have a corresponding artefact, and an agency that cannot produce any of them is describing an intention rather than a practice. The scorecard in this guide lists what to ask for against each area.

4. Why is a very low quote a warning sign?

   A low initial price can leave out review, testing or maintenance that you later have to pay for. Poorly written code is harder to update. Veracode's 2025 GenAI Code Security Report found security flaws in 45% of its tested generation tasks; that finding supports checking an agency's review process. Price alone does not establish how it uses AI.

5. What should I ask an agency about how it uses AI?

   Ask them to walk you through how they use AI in their process: what tasks it handles, what it does not, and what checks exist before that work ships. A good answer is specific and honest about trade-offs. A vague answer about 'leveraging AI to accelerate development' is the one you do not want. The strongest follow-up is to ask for a case where they rejected an AI-generated solution and what made it wrong.

6. Who owns AI-generated code in an agency project?

   Under US Copyright Office guidance, copyright protection depends on sufficient human authorship; prompting or reviewing an output alone does not establish it. Ask the agency to document human contributions, assign the rights it can transfer, and explain third-party licence obligations and how it checks generated code for copied material. Have counsel check the agreement under the law that applies to your project.

7. What should I ask about accounts and access before signing?

   Ask who will hold the source repository, the cloud accounts, the domain registrar, the error tracking and analytics, and for mobile work the Apple and Google developer accounts. The safest arrangement is that these are created under your organisation from the start and the agency is granted access, rather than created under the agency's and transferred later. Transfers can be slow or, for some app store accounts, awkward enough to delay a release.