Choosing a software agency is the most expensive decision you make before a single line of code exists. Most projects don't fail at the technology — they fail before it: at unclear requirements, missing ownership and expectations that were never spoken aloud. The Standish CHAOS report has shown a sobering picture for years — only about 31% of IT projects count as successful, roughly half are "challenged" and the rest fail outright. The single most important success factor isn't a technology, but a clear statement of requirements.
Hamburg in particular brings very different business environments together: established SMEs, logistics, commerce, media, industry, startups and digital platforms. A good agency therefore needs more than fluency in frameworks — it first has to clarify which business problem should actually be solved. From our perspective at hafencity.dev, the following criteria help you evaluate a software agency on substance, not gut feeling.
Most projects fail before the first line of code
A serious software agency doesn't begin with designs, frameworks or a fixed price — it begins with questions. This is exactly where later success is decided: Which business goals should the software support? Who uses the product internally and externally? Which processes, systems and data sources already exist? What is critical and what is merely nice to have? And where do risks lurk around budget, timeline, privacy, integrations or operations?
This discovery phase doesn't have to be oversized. For small projects a structured workshop is often enough; for complex platforms, apps or internal tools, more analysis, technical review and prioritization are needed. What matters is the outcome: sharpened requirements, tested assumptions and a first sensible scope. Without this step, teams build solutions that are technically delivered but miss the real problem — which matches the CHAOS data, where small, clearly scoped projects succeed far more often than large, vaguely defined ones.
Technical ownership is inseparable from this. Good agencies think beyond the single sprint: Does the architecture fit the expected usage? Will the system stay stable as data grows? Are roles, permissions and integrations modeled cleanly? Can another team continue later? An agency that answers every question with "everything is possible" without naming trade-offs isn't taking ownership — it's shifting the risk to you.
What a good agency costs — and why cheap gets expensive
The lowest price is rarely the cheapest. Software projects contain uncertainty, and a very low fixed price is only reliable when scope, quality and responsibilities are clearly defined. Otherwise the cost arrives later — through change requests, technical debt and poor maintainability. How a supposed bargain turns into an expensive project is something we covered in detail in Why cheap software gets expensive.
For orientation: agencies with an established team typically charge €120 to €180 per hour in the DACH region in 2026. Senior freelancers average around €95 to €110 according to the Freelancer-Kompass by freelancermap; a low-code builder starts at roughly €30 per month.
| Model | Typical rate (DACH, 2026) | Strong at | Weakness |
|---|---|---|---|
| Agency team | €120–180/h | ownership, architecture, operations | higher daily cost |
| Senior freelancer | ~€95–110/h | focus, flexibility | bus factor of 1, no team |
| Low-code / builder | from ~€30/month | speed for standard cases | limits, lock-in |
The figures are reference points, not quotes — but they expose the real criterion: you aren't only paying for development hours, but for ownership, architecture and operations over years. A realistic proposal therefore includes a clear scope, visible assumptions, boundaries, milestones, notes on technical risks and a process for handling changes during the project.
Quality you can verify
Code quality isn't a developer detail — it's a business factor. It decides how quickly new features ship, how often bugs appear and whether another team can take the product over later. A good agency can explain concretely how quality is created day to day — not abstractly, but through verifiable signals.
Look for clean architecture and clear module boundaries, code reviews, consistent linting, traceable documentation and version control with clear pull requests. Add automated tests where they make economic sense: unit tests for core logic, integration tests for interfaces, end-to-end tests for critical user journeys. A good agency doesn't test maximally — it justifies where tests protect budget and trust. You can go deeper via our piece on the software audit and code review.
Two quality dimensions are no longer optional in 2026. Accessibility has been mandatory for many digital products and services since the Accessibility Strengthening Act (BFSG) took effect on 28 June 2025; violations can be fined up to €100,000 per the BFSG guide. What that means in practice is summarized in our BFSG and WCAG checklist. And SEO doesn't start with a few keywords at the end, but with information architecture, performance (Core Web Vitals), clean metadata and internal linking — accessibility and performance often working hand in hand.
Ownership doesn't end at launch
Launch is rarely the end of a software project — it's the start of its operation. New requirements, security updates, browser changes, monitoring and sometimes strategic shifts all follow. Who operates the application? Who reacts when errors occur? How are updates deployed, are there backups, how are new features prioritized and how is knowledge documented? These questions belong before the contract, not after. We broke them down in detail in Software maintenance and further development.
Closely tied to this is dependence. A good agency works so you don't end up in a dead end: your own access to repositories and hosting, documented architecture and standard technologies instead of proprietary building blocks. The goal isn't that another team takes over — it's that it always could. That stance is exactly what separates a vendor who only sells the first build from a partner who stands behind a durable result.
Warning signs and the right questions
A single warning sign isn't a deal-breaker — but if several pile up, you should ask more detailed questions. Be skeptical when a proposal arrives before the requirements are understood, when risks aren't named, technical decisions aren't explained or tests, code reviews and maintenance aren't mentioned at all. When SEO, performance or accessibility only appear as a final add-on, or an agency won't plan handover and repository access, the necessary ownership is often missing.
A first call doesn't have to be deeply technical, but it should show whether the agency thinks in a structured way. These questions help:
| Question in the first call | What a good answer aims for |
|---|---|
| How would you analyze our project in the first phase? | structured discovery, not an instant fixed price |
| Which information do you need for a reliable estimate? | named assumptions and open risks |
| What does your process for code reviews and tests look like? | concrete practice, not buzzwords |
| Who handles maintenance and development after launch? | clear responsibility and handover |
| What would you advise us not to build? | honesty about value and budget |
The answers don't need to sound perfect. They should be concrete — and a good agency will also say when a request doesn't fit the budget, timeline or product goal.
Next steps
Three questions create clarity faster than any glossy pitch:
- Problem: Is the business problem to be solved clearly described — or are you ordering a solution before the problem is settled?
- Quality: Can the agency concretely evidence code reviews, tests, accessibility and performance?
- Operations: Is it clear who is responsible after launch and what a handover would look like?
If you're currently evaluating a software agency in Hamburg, a structured first call helps more than another feature list. Take a look at our software development or book an intro call directly — we'll frame your project honestly, including the risks and the first sensible scope.
