Agreements and guarantees
Which concrete agreements provide control over cost, quality, ownership, transferability, and aftercare? A guarantee is only worth something when it helps you in the day-to-day work. That is why we make clear agreements about hours, services, ownership, and handover in every collaboration.
Why guarantees matter
With critical software you want concrete commitments
Not marketing jargon. What you can expect from us when an audit exposes an issue, when substance needs to move fast, or when a component from the first build phase does not work as agreed shortly after go-live: that has to be crystal clear.
So we stay close to practice: technical and checkable, without marketing getting in between.
Commitments and working agreements
Seven topics that make collaboration predictable
A budget agreement only helps when it is clear when it holds. We therefore link a cost guarantee to a pessimistic estimate for a fixed scope.
After delivery, an agreed warranty period applies in which we fix bugs or technical problems that stem from the initial development at no extra cost.
If an independent security audit identifies delivery issues, we resolve them according to the agreements made, without extra cost to you.
We do not let substantive questions move unnecessarily through layers. With business-critical software especially, you want to talk directly with the people who understand the technical consequences.
Everything we create on behalf of a client belongs to that client. We always hand over the code we develop, so you are free to continue working on it internally or with another party.
Tickets and concrete context make work visible. Where possible, we link activities to traceable sources, so nobody has to wonder where the time went.
We also make general terms and matters such as payment deadlines clear and practical, without unnecessary ambiguity.
A cost ceiling with conditions
Cost guarantee
A budget agreement only helps when it is clear when it holds. We therefore link a cost guarantee to a pessimistic estimate for a fixed scope.
Starting point
Clear agreements create trust
Trust is indispensable, but checkable agreements are just as important. We explain upfront how we invoice, what hour reporting means, which external tools we use, and what exactly happens with the code and infrastructure.
That openness feels good at the start and, more importantly, prevents trouble when a project grows, changes direction, or eventually has to be handed over to someone else.
What guarantees are not
No replacement for a sound process
Ultimately, the best guarantee is still a well-built project.
Direct contact, a bounded scope, quality gates, release management, and monitoring together reduce the chance that you later need to rely on the guarantee. It is part of how we work, not something separate from it.
The precise wording can differ by assignment. We therefore state the principles transparently and work out the details for each collaboration.
Why this makes a difference
Transparency must also hold up operationally
Transparency means being clear about costs, completed work, and ownership.
An estimate is never just an abstract number: you can see the individual components that make up the completed work. Intellectual property does not remain in someone else's name, and you should not have to wrestle with infrastructure that stays tied to the supplier simply because that is how it was once set up.
Organisations that run on business-critical software experience these details every day. One incorrectly arranged ownership line can cause problems for years when priorities, teams, or suppliers change. That is why direct access to code, documentation, and Glossary · In briefchangelogA changelog is a record of relevant software changes, usually organized by version or release. It includes new features, bug fixes and changes that affect users.Read more is part of how we build transferability from the start.
What this gives you
Serious follow-up on audit findings
An agreed warranty period for bug fixes after delivery
More insight into what was done and why
Clarity on code ownership and infrastructure
Less dependence on a specific supplier
Frequently asked questions
Problems traceable to the initial development are fixed free of charge within the agreed warranty period.
If you later request something different, that follows a separate set of agreements about new requirements and additional functionality.
There is no all-encompassing no-worries clause. Control over planning and budget comes from clearly bounded scope, the way we develop, and the agreements around time and materials. A conditional cost guarantee can also apply while scope remains unchanged.
The client does. For us, transferability and freedom of choice belong to a healthy collaboration; they are not optional extras.
The principles remain the same, but the precise wording in a contract can differ by assignment. We state the principles as transparently as possible so the details can be worked out for each new collaboration.
Is your question not listed here?
Get in touch