Demand in Hamburg comes from trade, logistics and media rather than from startups
The shape of a local software market follows the businesses that pay for software, and here those are freight forwarders, shipping and port related services, wholesale and import businesses, insurance and a substantial publishing and advertising sector. That produces a specific kind of brief. It is rarely a consumer product. It is usually a system that moves documents, tracks shipments, reconciles data between parties who do not share a database, or manages rights, assets and campaigns across a media operation.
The evaluation follows from that. Software in these sectors is judged on whether it handles the exceptions, not on whether it handles the happy path. A forwarding business cares about the shipment that arrives with the wrong paperwork. An insurer cares about the claim that does not fit the product. Ask candidate suppliers to walk through how their proposed design handles the ugly cases in your process, and treat a demo that only shows the clean flow as an unfinished answer.
The contract type decides who carries the risk
This is the single most consequential local difference, and buyers from outside the country routinely miss it. German contract law distinguishes between an agreement to deliver a defined result and an agreement to provide services. Under the first, the supplier owes you a working outcome, there is a formal acceptance step, and statutory warranty obligations follow. Under the second, the supplier owes you competent effort and time, and the outcome risk is yours.
Both are entirely normal and both are used. The problem arises when the commercial conversation describes one and the signed document constitutes the other. A proposal that talks about delivering a finished platform while the contract is drafted as a service agreement billed by the hour leaves you holding a risk you thought you had transferred. Ask directly which type is intended, and make sure the acceptance clause, the warranty clause and the payment schedule are consistent with the answer.
Acceptance, defects and planning for the handover
Where the agreement is for a defined result, acceptance is not a formality, it is the moment liability and warranty periods start and payment becomes due. Plan it properly. Write down what will be tested, by whom, against which criteria, over what period, and what happens if your side does not respond in time. Agree how minor defects are handled, since a system is normally accepted with a defect list rather than blocked by it, and agree which classes of defect do block acceptance.
Plan the handover as a deliverable in its own right. Source repository access, build and deployment instructions, environment configuration, a data dictionary and an operational runbook. Firms that build in this market for industrial clients usually have a standard package for this, because their clients are used to demanding documentation from every other supplier they deal with. If a development firm treats documentation as optional, that is a signal about who their clients have been.
Data protection and the works council are design constraints
Everyone in this market says they are compliant with data protection law, and that statement alone is worth nothing. The useful questions are concrete: where will the data physically sit, which processors are in the chain, what is the deletion policy, how is a data subject request actually serviced in the system you are proposing, and is there a processing agreement ready to sign.
The second constraint is less familiar to foreign buyers and much more likely to delay a launch. If the software can be used to monitor employee performance or behaviour, and a great deal of operational software incidentally can, the employee representative body in your organisation has genuine co-determination rights over its introduction. That is not a legal footnote, it is a real approval path with its own timeline. Systems that log who did what and when, track productivity, or record location need that conversation started early. Ask whether your supplier has been through it before, because one that has will design reporting differently, aggregating where it can rather than exposing individual level metrics by default.
Pricing structures and what each assumes
Fixed price suits work with a demonstrable target, typically the replacement or extension of something that already exists, and it fits naturally with a result based contract and milestone payments. It requires a specification detailed enough to defend and a change process everyone respects.
Billing by time suits integration work and discovery, where the unknowns sit inside systems that belong to other parties, and it requires you to provide a decision maker with real authority. A capped arrangement combines the two and is often the fairest first phase. Ongoing team arrangements suit long running product development but need a periodic review that asks whether the output still justifies the cost. Choose according to how much genuine uncertainty exists, and be suspicious of a firm that offers a firm price for a brief you know to be vague.
Building a shortlist of software companies in Hamburg
Keep it to three or four firms and brief them in writing with the same document. What you are comparing is not the headline figure, it is the quality of the assumptions underneath it, and the lowest number generally belongs to whoever understood the least about your exceptions.
Ask each firm for a single page stating their reading of the scope, their exclusions, the named people who would work on it, what they require from you and what they see as the main risk. Ask for a reference in your own sector and speak to someone operational rather than to the executive sponsor. Sector familiarity matters more than general craft here, because a team that has integrated with customs or freight systems before will estimate that work realistically, and a team learning it will do so on your budget.
If your requirement extends to public facing channels, it is usually better to engage separate specialists such as web design agencies working in the city or mobile app developers than to stretch one supplier across everything. The broader list of verified development firms sits in the software development company directory, and where a specialised skill is genuinely scarce, supplier pools in Berlin and Munich work in the same language and time zone. Once the scope is written, request comparable proposals from several verified suppliers so that every quote answers the same question.