How to vet an agency: case studies, certifications, credentials

Why case studies alone aren't enough

A client logo on a website proves little; a certification, by contrast, can be checked. This simple distinction helps with almost any assessment of an agency, and yet it's hard to apply in practice, because a polished portfolio looks credible without necessarily being so. Case studies should therefore include a concrete, measurable claim. "Cut turnaround time from four days to a day and a half" is a claim; "successfully implemented" is not. For every case study, ask for the number behind it: how much faster, cheaper, or more error-free has a process become since? And ask whether a direct conversation with the reference client is possible. Agencies that consistently deliver good work usually arrange this without hesitation, because they know their past clients speak for them.

Also check how recent the case studies are. A project from 2021 says little about the current state of a team, stack, or process, especially in fast-moving fields like machine learning or LLM integration, where tools and best practices shift noticeably within a few years. Ask for one or two projects from the last twelve months, and what's changed since then.

Credentials that can actually be checked

Not every seal means the same thing. ISO 27001 shows a working information security management system and matters wherever sensitive data is involved. TISAX is mandatory for many suppliers in the automotive industry. AWS, Microsoft, or Google Cloud partner status proves vetted competence with that specific provider, similar to Shopware or Shopify partner status in e-commerce. GDPR-compliant data processing and EU hosting should go without saying, but in practice they don't always. A written data processing agreement (DPA) should therefore be on the table in every case. For AI projects, classification under the EU AI Act has applied since 2025: an agency that can assign your use case to a risk category itself and supply the matching documentation saves you work later on.

A certificate alone doesn't say whether it's still valid, though. Ask for the issue date and, for ISO 27001, the date of the last surveillance audit. An expired certificate on a website is no longer proof of anything, just a reminder of a past state.

For penetration tests and security audits, it's also worth checking the qualifications of the individual testers, such as a recognized certification like OSCP. A company-level certificate says little about who's actually at the keyboard on your project. Ask for an anonymized excerpt from a past test report. That shows the real depth of the work far more clearly than any logo.

How a verified profile on techagenturen.de comes about

On techagenturen.de, a credential only appears on a profile after our editorial team has seen the underlying document. So a certification is never shown based on self-reporting alone. Verified also means the agency's identity and domain have been checked against its legal notice (Impressum). Verification is valid for twelve months and is independent of whether an agency has booked a paid plan: a paid listing changes neither the review nor the ranking. This doesn't replace your own due diligence for a first call, but it shortens it: you start with a shortlist where the crudest claims have already been filtered out.

Who on the team you're actually hiring

A convincing first call is often led by management or an experienced salesperson, not the developers who will actually work on the project later. That's normal, but it shouldn't be the final word. Ask specifically for the names of the people who will build your project and their experience with a comparable undertaking. For larger projects, a short introductory call with the technical lead is worth arranging before the contract is signed. Also check the split between senior and junior time in the proposal: a team made up mostly of entry-level developers isn't automatically worse, but that should be reflected in the hourly rate and in quality assurance. If the question about the actual team gets an evasive answer, that's already an answer in itself.

Another signal is availability over the course of the project. Some agencies put their best people forward during the proposal phase, then switch to a cheaper, less experienced team afterward, a pattern best prevented by naming fixed points of contact in the contract. Get the names and roles of the core team in writing in the proposal or contract, rather than just mentioned verbally in the first call.

What you should bring to the conversation yourself

A good first call requires preparation on both sides. Bring along a rough description of the project, even if it's just one page: the goal, an approximate scope, existing systems the solution needs to talk to, and a realistic budget range. Without this information, every answer from the agency stays noncommittal, because it can only guess otherwise. Clarify internally beforehand who makes the final decision and who's available as a point of contact during the project. That speeds up later coordination considerably. If you'd rather structure your project in writing first, the article on software requirements specifications offers a suitable outline for that.

The first call: questions to ask

The following questions can be covered in a single call, and after just a few answers, they usually show whether an agency is a fit for your project.

1. Which credentials are verified, and who verified them?
2. Who actually works on the project, not just in sales?
3. Can you give me a case study with a concrete metric, not just a description?
4. Can I speak directly with a reference client?
5. How is code ownership regulated in the contract, and what's included in the handover?
6. Which contract model do you recommend for my project, and why that one specifically?
7. What does a realistic effort estimate for my project look like, in hours or person-days?
8. Do you work with subcontractors or a nearshore team, and if so, what share of the work?
9. How does communication work during the project, and how often is there a status report?
10. What happens if a key team member is unavailable or leaves the project?
11. How are data processing, hosting, and the data processing agreement handled?
12. What notice period and handover deadlines apply in your standard contract?

For the question about code ownership, some reading beforehand pays off: the article Code ownership and usage rights explains which contract clauses are standard.

Warning signs you should take seriously

Some answers say more than any certificate. A fixed price without a prior requirements phase is one of the most common warning signs, because a realistic price is hard to calculate without first clarifying scope. Case studies with no concrete result, evasive answers on code ownership and handover, and a stack that supposedly covers everything belong on that list too. Credible providers, by contrast, name their limits and explain which contract model fits your project and which doesn't. Be cautious of pressure to sign quickly, or a quote noticeably below every other one without an explanation for the difference in scope. Another pattern: promises made only verbally that then go missing from the written proposal, for example on response times or the scope of maintenance after the project ends. What counts is in the contract, not in the sales pitch.

Two or three candidates in direct comparison

Collecting more than three proposals at once usually costs more time than it adds in extra certainty. Narrow down the service first, such as custom software, IT security, or AI strategy consulting, and only then filter by stack, credentials, and budget. In the search, these criteria can be combined without going through every profile individually. If you'd rather just describe your project, a request gets you proposals from up to three matching, verified agencies without having to do the shortlisting yourself. For which questions to ask when comparing the actual proposals afterward, see the article Comparing agency proposals.