How to Choose a Software Development Company in Germany: The Questions That Reveal Real Quality

Every few weeks someone emails me after a bad experience with a software development company in Germany. The pattern is always similar. The sales calls were smooth, the proposal looked professional, the price sat mid-market, and nine months later they have a codebase nobody wants to touch and a vendor who bills for every change request.

The German market has a lot of agencies. The quality variance between them is enormous, and pricing tells you almost nothing about which one you are talking to. A 140 EUR hourly rate can buy you a senior engineer in Leipzig or a junior in a Berlin coworking space with a senior's name on the invoice.

This post is the evaluation process I would use as the buyer. I apply the same checks in the other direction when deciding whether a client fits Wolf-Tech, so none of it is theory.

Start with the portfolio, but read it differently

Most buyers skim a portfolio for recognisable logos and a technology list. Both are close to worthless. Awards and "Top 10 Agency" badges are mostly pay-to-play, and a wall of framework logos tells you what the marketing team thinks sounds impressive, not what the engineers have shipped.

What you should read in a case study instead:

Is it recent? A portfolio whose newest entry is from 2022 means either the company has not done interesting work since or cannot get permission to talk about it. Both are worth asking about.

Does it name the client? NDAs are real, and some clients cannot be named. But an agency where every single case study hides behind "a leading logistics company" has either no client willing to vouch for them or no real client at all. One or two named references with a contact you can actually email are worth more than twenty anonymous ones.

Can they describe the starting situation? A good case study explains what the client's problem was before the engagement. "We built a platform for X" is a sentence anyone can write. "The client had a PHP 7.2 monolith with a 40 minute deploy and an ordering process that lost transactions under load" is a sentence you can only write if you were there.

Does it mention technical specifics or only outcomes? "Increased conversion by 30 percent" is a marketing outcome. "Moved the checkout to an asynchronous queue and cut p95 latency from 4.1 seconds to 600 milliseconds" is engineering. You want a vendor who thinks in the second language, because that is the language your future incidents will be written in.

The interview questions that separate senior from confident

Every agency will put a senior person in the sales call. Your job is to find out whether that person will be on your project, and whether the people who will be on it are actually senior.

Ask to speak with the engineer who would lead the work, not the account manager. If they refuse, that is the answer.

Then ask questions where a generic answer is a disqualifier. A few that work well:

How do you handle database migrations in production? A senior engineer will talk about backwards-compatible schema changes, expand and contract patterns, running migrations separately from deploys, and what happens on rollback. A junior will say "we use Doctrine migrations" and stop. If you want the level of detail a senior answer should contain, my zero-downtime migrations playbook is roughly what I would expect to hear.

How do you manage secrets? Listen for a secrets manager or at least environment injection at deploy time, rotation, and a clear statement that secrets are never in the repository. If the answer involves a .env file committed "to a private repo", walk away.

What happens when a dependency you shipped gets a security vulnerability? This one exposes whether they have an operational process or just a build pipeline. Good answers mention automated dependency scanning, a defined response time, and who at the agency is responsible after the project is handed over. Vague answers ("we keep things up to date") mean nobody owns it.

How do you decide what gets a test? Not "do you write tests", which everyone says yes to. The good answer explains where tests pay for themselves (domain logic, money, permissions, integrations) and where they do not. Someone who claims 100 percent coverage on every project is either lying or wasting your budget.

Show me a pull request review from a recent project. Anonymised is fine. What you are looking for is whether reviews contain substance (security, data integrity, coupling) or only formatting nitpicks and "LGTM". I wrote up what a senior code review actually catches if you want a benchmark for comparison.

Evasive or generic answers to any of these are disqualifying. A senior engineer enjoys these questions; they are the interesting part of the job.

Contract red flags that German agencies routinely bury

The contract is where the good and the mediocre agencies look most alike on the surface, so read it properly. Ideally with a lawyer, but at minimum yourself, and specifically for these points.

IP ownership. Under German copyright law (Urheberrecht), the developer keeps authorship and you receive usage rights. That is normal. What matters is whether those rights are exclusive, unrestricted, transferable and cover all forms of use, and whether they transfer on payment of each invoice or only after the final one. Agencies sometimes place a clause deep in the AGB that keeps rights with them until "full settlement of all claims", which gives them leverage in any later dispute. Ask for the IP clause to be pulled into the main contract where you can read it.

No source code escrow or repository access. You should have admin access to the repository from day one, in your own GitHub or GitLab organisation if possible. If the agency insists on hosting the code in their account and "handing it over at the end", you have no protection if the relationship sours or the company folds. Escrow is the formal version of this; for most mid-size projects, owning the repository is enough.

Undefined change request process. A fixed price contract with no defined procedure for changes is a fixed price contract that will not stay fixed. You need to know who approves changes, how they are estimated, what the hourly rate is for out-of-scope work, and how disputes over whether something is "in scope" get resolved. If the contract is silent, the agency decides, and they decide in their own favour.

Staffing clauses. Look for whether the contract names the people or at least the seniority levels assigned, and whether the agency can swap them without your consent. The bait and switch from senior in the pitch to junior on the project is the single most common complaint I hear.

Warranty and defect handling. A Werkvertrag gives you defect rights; agencies often prefer a Dienstvertrag, where they owe effort rather than results. Neither is wrong, but know which one you are signing.

Prefer a discovery phase over a fixed price for an unspecified product

A fixed price for a product that has not been specified in detail is a guess dressed up as a commitment. The agency knows this. They protect themselves either by padding the price heavily, or by pricing low and recovering the margin through change requests later. In the first case you overpay. In the second case you get the nine month nightmare from the opening of this post.

The alternative is a paid discovery phase: two to four weeks in which the agency works with you to produce a real specification, an architecture proposal, a prioritised backlog and a realistic estimate with stated assumptions. You pay for that work. At the end you own the output and can take it to any vendor, including a different one.

Agencies that are confident in their quality tend to like this model because it lets them show their work before anyone commits to a large sum. Agencies that resist it and push straight for a signed fixed price are, in my experience, the ones whose estimates you should trust least. I described how the engagement should look after discovery in how to run a sprint with an external development partner.

If you are still deciding between a larger agency and a smaller consultancy for the work, the consultancy versus agency comparison covers the tradeoffs.

What to ask previous clients

References will be happy clients, because that is how references work. You can still get real information out of them with questions they were not prepped for.

Ask what went wrong. Every project has something. A reference who says "nothing" is either not being candid or was not close enough to the work to know. A reference who says "the first estimate was off by about 30 percent, but they told us early and we re-prioritised" is telling you something useful about how the agency behaves under pressure.

Ask who actually did the work, and whether those people are still at the agency. Team turnover at agencies is high. The engineers who built the reference project may have left two years ago.

Ask what happened after handover. Did the agency stay reachable? Did the client find problems in the code once their own team took it over? Did another vendor later review the code, and what did they say? This last one is where the honest answers live.

Ask whether they would hire them again for a different kind of project. The phrasing matters. "Would you recommend them" gets a reflexive yes. "Would you use them for a greenfield SaaS build if the reference project was a website" forces the reference to think about the agency's actual range.

How Wolf-Tech evaluates fit from the other side

For what it is worth, these are the questions I ask myself before accepting a client, because a bad fit costs both sides.

Does the client have a technical decision maker I can talk to directly, or does everything go through a project manager who cannot evaluate what I say? Projects without a technical counterpart drift.

Is the scope specified enough to estimate, or are they asking for a fixed price on an idea? If the latter, I propose discovery first, and if they refuse, I usually decline.

Are they willing to give me repository and infrastructure access under their own accounts? Clients who want me to work in a black box and hand over a zip at the end are asking for exactly the setup I warned about above.

Have they had a previous vendor, and can they explain what went wrong without blaming everything on the vendor? A client who has never been at fault in three vendor relationships is going to have the same experience with a fourth.

Do they need a custom software build, a review of code they already have, or help modernising a legacy system? These are different engagements, and a client who is unsure which one they need usually benefits from a short audit before anything else.

A short checklist for the first call

Before you sign anything with a software development company in Germany, you should be able to answer yes to each of these: you have spoken to the engineer who will lead the work, you have seen a recent case study that names the client and describes the technical starting point, you know how they handle migrations, secrets and vulnerable dependencies, you have read the IP and change request clauses yourself, you will own the repository from the first commit, and you have asked at least one reference what went wrong.

If any of those is a no, you do not yet know enough to sign.

If you want a second opinion on a proposal you have received, or an independent review of a codebase a previous vendor left behind, write to hello@wolf-tech.io or have a look at what I do at wolf-tech.io. I am happy to tell you if a proposal looks reasonable even when the work is going to someone else.