Custom software development differs from other IT projects in that not every detail is settled at the start — and commissioning it should take that into account. A company that demands a fixed-price offer for a project whose scope only becomes clear as it progresses will get either an unrealistically low price followed by change orders, or an unrealistically high one with risk priced in. A company that instead has development run purely on a time-and-materials basis with no structure easily loses track of progress and cost. This guide describes the points to clarify before commissioning, so both sides share the same expectations from the start.
Clarify the goal and scope
Start by describing the software's actual goal, not just a list of desired features: what problem needs solving, for whom, and how would you recognize that the software achieves that goal? Also distinguish between a minimal viable first scope (often called an MVP) and the full, long-term desired feature set. This distinction helps break a project into manageable stages, instead of commissioning one very large, hard-to-estimate package from the start. A provider who knows the actual goal can also bring their own suggestions for how to achieve it more simply or cheaply than a pure feature list would allow.
Fixed price vs. time and materials
The same basic rule applies to custom software development as to other IT projects: a fixed price fits a clearly bounded, well-described scope, while billing by effort (hourly or daily rate) fits projects better where the scope only becomes concrete as the project progresses. For custom software, the latter is more the rule than the exception, because requirements often only sharpen once the first visible results appear. A common middle-ground model is a fixed price per stage or sprint within an overall open scope — that limits the risk to a manageable period without fixing the entire project scope from the start. Which model fits depends on how mature your requirements are; the guide to comparing offers explains the common pricing models in detail.
Iterations and collaboration
Clarify at what rhythm you'll see interim results and can give feedback — weekly, after each completed feature, or only at the end of the project. Regular, short iterations with visible interim states reduce the risk of ending up with a result that matches the original description but no longer matches the actual need. Name one person on your side who's available for domain questions during the project — a project without an available point of contact regularly gets delayed in practice, because the provider has to wait for answers to keep working.
Clarify usage rights and source code
Clarify what usage rights you'll receive (exclusive or non-exclusive), whether the source code is handed over, and from when — for example after full payment. This guide deliberately names this only as an open question to clarify, not as a legal assessment, since the exact arrangement depends on the individual case and the applicable law. Also ask whether and to what extent external libraries or third-party components are used and under what license terms, since that can affect later use and further development. Have contractual arrangements around usage rights — especially if further development by a different provider is planned — reviewed by your legal counsel or specialized advice if in doubt, rather than relying on a verbal assurance.
Quality assurance and testing
Clarify who's responsible for testing during development and to what extent automated tests are part of the deliverable. A provider who plans automated tests for core functionality from the start makes later changes considerably easier, since bugs introduced by new features can be found faster than with purely manual checking. Also ask how bugs found during a running iteration are handled — fixed immediately, or collected and addressed at the end of the stage? Without a clear agreement on quality assurance, testing often gets pushed entirely to the end of the project, where fixes are more effort and more expensive than during ongoing development.
Operations and maintenance after launch
Software doesn't end at completion: clarify who takes over ongoing operations — hosting, updates, security fixes — and whether a separate maintenance contract is planned for that. Clarify how long and to what extent the provider stands behind defects, and whether the contract modifies the statutory warranty — that also depends on whether the contract is structured as a work contract or a services contract under German law. A project that doesn't plan for the time after go-live regularly ends up with a gap where no one is responsible for issues that come up.
Sign-off
Before the project starts, define the criteria you'll use to sign off on the software — such as defined test cases that need to pass successfully, or a joint review of the core functions against the originally described goal. Without such criteria, it stays unclear when a project is really finished, and disagreements about necessary rework are practically guaranteed. The guide to writing a scope description shows how to capture the goal, scope and sign-off criteria in the request itself. If it's instead about rolling out an existing standard or business software rather than building something new, the guide to an ERP rollout is the better starting point.
Checklist
- Actual goal described, not just a feature list
- MVP and long-term full scope distinguished
- Pricing model chosen to fit how mature the requirements are
- Iteration rhythm and an internal point of contact defined
- Usage rights to the code and third-party components named as a point to clarify
- Responsibility for testing and handling found bugs agreed
- Operations, maintenance and warranty after launch clarified
- Sign-off criteria defined before the project starts
If you want to move forward with a custom software project, you can describe it on Projektlotse — with the goal, scope and constraints from this guide. Verified IT providers in your region see the request and get in touch with questions and offers. Your company name, exact address and attachments stay confidential until you release them to individual providers. Use is free during the current start phase.